Menu
▾
▴
mailcrypt-bugs
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(4) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(21) |
Jul
|
Aug
|
Sep
(11) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(4) |
Nov
(3) |
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
|
Jul
(6) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(3) |
Dec
(2) |
| 2006 |
Jan
(4) |
Feb
(4) |
Mar
(3) |
Apr
(4) |
May
(4) |
Jun
(14) |
Jul
(10) |
Aug
(4) |
Sep
(1) |
Oct
(20) |
Nov
(17) |
Dec
(13) |
| 2007 |
Jan
(34) |
Feb
(21) |
Mar
(27) |
Apr
(26) |
May
(16) |
Jun
(13) |
Jul
(37) |
Aug
(27) |
Sep
(25) |
Oct
(11) |
Nov
(9) |
Dec
|
|
From: Joseph S D Y. <js...@tu...> - 2005-11-10 00:42:11
|
OK, I said I'd take care of this, and I will. My apologies if this is going out to too many people, but with so many mailing lists involved, I'd rather that this get to everyone who needs to see it than miss a number of important addressees. We need to clean up the @xemacs.org addresses being hosted on @tux.org. Right now, they are merged in with all other @tux.org e-mail addresses. The first list that follows is the list of aliases defined by the xemacs aliases file. As aliases, they are indistinguishable from any other e-mail addresses coming onto this e-mail host. One problem is, that some of these conflict with other aliases, specifically: MAILER-DAEMON, hostmaster, mailman, mailman-owner, postmaster, webmaster Another problem is that no...@xe... users are being sent SPAM to @xemacs.org mail addresses, and don't like it. The second list below is that of the e-mail addresses in the alias definitions who are in the @xemacs.org domain. Some of them don't even exist! I am going to fix the problem by making @xemacs.org into a partial virtual domain, rather than having it [as now] as another name for @tux.org. QUESTIONS: (1) Are all the mailing lists in List 1, below, still needed and used? More specifically, are there any I should throw out? [And if any of them bounces, I am throwing it out - or at least commenting it out.] (2) Are the aliases in /etc/mail/aliases-xemacs still valid? Are there any translations that need to change? (3) Are there any more e-mail addresses that should respond to @xemacs.org than the ones listed below? Because if I don't explicitly include them, they will no longer be part of the @xemacs.org domain. (4) Are there real e-mail addresses that should be associated with the alias targets that don't exist (in List 2)? (5) What are your maintenance needs for these mailing lists? (6) Is there any need to make this a full virtual domain, so that any and ALL e-mail sent by certain users will appear to be coming from @xemacs.org? Thanks! List 1 - aliases ======================================================================= MAILER-DAEMON ada-bugs ada-discuss ada-maintainer ada-patches apel-bugs apel-discuss apel-maintainer apel-patches auctex-bugs auctex-discuss auctex-maintainer auctex-patches bbdb-announce bbdb-announce-request bbdb-bugs bbdb-discuss bbdb-info bbdb-info-request bbdb-maintainer bbdb-patches bugs c-support-bugs c-support-discuss c-support-maintainer c-support-patches calc-bugs calc-discuss calc-maintainer calc-patches calendar-bugs calendar-discuss calendar-maintainer calendar-patches cookie-bugs cookie-discuss cookie-maintainer cookie-patches crashes crisp-bugs crisp-discuss crisp-maintainer crisp-patches cvs-manager cvs-manager-archive debug-bugs debug-discuss debug-maintainer debug-patches dired-bugs dired-discuss dired-maintainer dired-patches edebug-bugs edebug-discuss edebug-maintainer edebug-patches edict-bugs edict-discuss edict-maintainer edict-patches ediff-bugs ediff-discuss ediff-maintainer ediff-patches edit-utils-bugs edit-utils-discuss edit-utils-maintainer edit-utils-patches edt-bugs edt-discuss edt-maintainer edt-patches efs-bugs efs-discuss efs-maintainer efs-patches egg-its-bugs egg-its-discuss egg-its-maintainer egg-its-patches eicq-bugs eicq-discuss eicq-maintainer eicq-patches eieio-bugs eieio-discuss eieio-maintainer eieio-patches elib-bugs elib-discuss elib-maintainer elib-patches emerge-bugs emerge-discuss emerge-maintainer emerge-patches escreen-bugs escreen-discuss escreen-maintainer escreen-patches eshell-bugs eshell-discuss eshell-maintainer eshell-patches eterm-bugs eterm-discuss eterm-maintainer eterm-patches eudc-bugs eudc-discuss eudc-maintainer eudc-patches faq faq-maintainer footnote-bugs footnote-discuss footnote-maintainer footnote-patches forms-bugs forms-discuss forms-maintainer forms-patches frame-icon-bugs frame-icon-discuss frame-icon-maintainer frame-icon-patches fsf-compat-bugs fsf-compat-discuss fsf-compat-maintainer fsf-compat-patches games-bugs games-discuss games-maintainer games-patches gnats-admin gnats-bugs gnats-discuss gnats-maintainer gnats-patches gnus-bugs gnus-discuss gnus-maintainer gnus-patches hm--html-menus-bugs hm--html-menus-discuss hm--html-menus-maintainer hm--html-menus-patches hostmaster hyperbole-bugs hyperbole-discuss hyperbole-maintainer hyperbole-patches idlwave-bugs idlwave-discuss idlwave-maintainer idlwave-patches igrep-bugs igrep-discuss igrep-maintainer igrep-patches ilisp-bugs ilisp-discuss ilisp-maintainer ilisp-patches ispell-bugs ispell-discuss ispell-maintainer ispell-patches jde-bugs jde-discuss jde-maintainer jde-patches kit-manager latin-euro-standards-bugs latin-euro-standards-discuss latin-euro-standards-maintainer latin-euro-standards-patches latin-unity-bugs latin-unity-discuss latin-unity-maintainer latin-unity-patches leim-bugs leim-discuss leim-maintainer leim-patches list-manager locale-bugs locale-discuss locale-maintainer locale-patches lookup-bugs lookup-discuss lookup-maintainer lookup-patches mail-lib-bugs mail-lib-discuss mail-lib-maintainer mail-lib-patches mailcrypt-bugs mailcrypt-discuss mailcrypt-maintainer mailcrypt-patches mailman mailman-owner majordomo majordomo-owner majordomo-xemacs mew-bugs mew-discuss mew-maintainer mew-patches mh-e-bugs mh-e-discuss mh-e-maintainer mh-e-patches mine-bugs mine-discuss mine-maintainer mine-patches misc-games-bugs misc-games-discuss misc-games-maintainer misc-games-patches mule-base-bugs mule-base-discuss mule-base-maintainer mule-base-patches net-utils-bugs net-utils-discuss net-utils-maintainer net-utils-patches oo-browser-bugs oo-browser-discuss oo-browser-maintainer oo-browser-patches os-utils-bugs os-utils-discuss os-utils-maintainer os-utils-patches owner-bbdb-announce owner-bbdb-info owner-majordomo owner-majordomo-xemacs owner-w3-announce owner-w3-beta owner-w3-bugs owner-w3-dev pc-bugs pc-discuss pc-maintainer pc-patches pcl-cvs-bugs pcl-cvs-discuss pcl-cvs-maintainer pcl-cvs-patches pcomplete-bugs pcomplete-discuss pcomplete-maintainer pcomplete-patches postmaster prog-modes-bugs prog-modes-discuss prog-modes-maintainer prog-modes-patches ps-print-nomule-bugs ps-print-nomule-discuss ps-print-nomule-maintainer ps-print-nomule-patches psgml-bugs psgml-discuss psgml-maintainer psgml-patches python-mode-bugs python-mode-discuss python-mode-maintainer python-mode-patches reftex-bugs reftex-discuss reftex-maintainer reftex-patches rmail-bugs rmail-discuss rmail-maintainer rmail-patches scheme-bugs scheme-discuss scheme-maintainer scheme-patches semantic-bugs semantic-discuss semantic-maintainer semantic-patches sgml-bugs sgml-discuss sgml-maintainer sgml-patches sh-script-bugs sh-script-discuss sh-script-maintainer sh-script-patches skk-bugs skk-discuss skk-maintainer skk-patches slider-bugs slider-discuss slider-maintainer slider-patches sounds-au-bugs sounds-au-discuss sounds-au-maintainer sounds-au-patches sounds-wav-bugs sounds-wav-discuss sounds-wav-maintainer sounds-wav-patches speedbar-bugs speedbar-discuss speedbar-maintainer speedbar-patches sql-mode-bugs sql-mode-discuss sql-mode-maintainer sql-mode-patches strokes-bugs strokes-discuss strokes-maintainer strokes-patches sun-bugs sun-discuss sun-maintainer sun-patches supercite-bugs supercite-discuss supercite-maintainer supercite-patches texinfo-bugs texinfo-discuss texinfo-maintainer texinfo-patches text-modes-bugs text-modes-discuss text-modes-maintainer text-modes-patches textools-bugs textools-discuss textools-maintainer textools-patches time-bugs time-discuss time-maintainer time-patches tm-bugs tm-discuss tm-maintainer tm-patches tooltalk-bugs tooltalk-discuss tooltalk-maintainer tooltalk-patches tpu-bugs tpu-discuss tpu-maintainer tpu-patches vc-bugs vc-cc-bugs vc-cc-discuss vc-cc-maintainer vc-cc-patches vc-discuss vc-maintainer vc-patches vhdl-bugs vhdl-discuss vhdl-maintainer vhdl-patches view-process-bugs view-process-discuss view-process-maintainer view-process-patches viper-bugs viper-discuss viper-maintainer viper-patches vm-bugs vm-discuss vm-maintainer vm-patches w3-announce w3-announce-approval w3-announce-out w3-announce-request w3-beta w3-beta-approval w3-beta-out w3-beta-request w3-bugs w3-bugs-approval w3-bugs-out w3-bugs-request w3-dev w3-dev-approval w3-dev-out w3-dev-request w3-discuss w3-maintainer w3-patches webmast webmaster xemacadm xemacs xemacs-admin xemacs-admin-admin xemacs-admin-bounces xemacs-admin-confirm xemacs-admin-join xemacs-admin-leave xemacs-admin-mailman xemacs-admin-owner xemacs-admin-request xemacs-admin-subscribe xemacs-admin-unsubscribe xemacs-announce xemacs-announce-admin xemacs-announce-archivist xemacs-announce-bounces xemacs-announce-confirm xemacs-announce-join xemacs-announce-leave xemacs-announce-mailman xemacs-announce-owner xemacs-announce-request xemacs-announce-subscribe xemacs-announce-unsubscribe xemacs-base-bugs xemacs-base-discuss xemacs-base-maintainer xemacs-base-patches xemacs-beta xemacs-beta-admin xemacs-beta-archive xemacs-beta-bounces xemacs-beta-confirm xemacs-beta-ja xemacs-beta-ja-admin xemacs-beta-ja-archive xemacs-beta-ja-bounces xemacs-beta-ja-confirm xemacs-beta-ja-join xemacs-beta-ja-leave xemacs-beta-ja-mailman xemacs-beta-ja-owner xemacs-beta-ja-request xemacs-beta-ja-subscribe xemacs-beta-ja-unsubscribe xemacs-beta-join xemacs-beta-leave xemacs-beta-mailman xemacs-beta-owner xemacs-beta-request xemacs-beta-subscribe xemacs-beta-unsubscribe xemacs-build-reports xemacs-build-reports-admin xemacs-build-reports-request xemacs-buildreports xemacs-buildreports-admin xemacs-buildreports-archive xemacs-buildreports-bounces xemacs-buildreports-confirm xemacs-buildreports-join xemacs-buildreports-leave xemacs-buildreports-mailman xemacs-buildreports-owner xemacs-buildreports-request xemacs-buildreports-subscribe xemacs-buildreports-unsubscribe xemacs-crashes xemacs-crashes-admin xemacs-crashes-archive xemacs-crashes-bounces xemacs-crashes-confirm xemacs-crashes-join xemacs-crashes-leave xemacs-crashes-mailman xemacs-crashes-owner xemacs-crashes-request xemacs-crashes-subscribe xemacs-crashes-unsubscribe xemacs-cvs xemacs-cvs-admin xemacs-cvs-archive xemacs-cvs-bounces xemacs-cvs-confirm xemacs-cvs-join xemacs-cvs-leave xemacs-cvs-mailman xemacs-cvs-owner xemacs-cvs-request xemacs-cvs-subscribe xemacs-cvs-unsubscribe xemacs-design xemacs-design-admin xemacs-design-archivist xemacs-design-bounces xemacs-design-confirm xemacs-design-join xemacs-design-leave xemacs-design-mailman xemacs-design-owner xemacs-design-request xemacs-design-subscribe xemacs-design-unsubscribe xemacs-devel-bugs xemacs-devel-discuss xemacs-devel-maintainer xemacs-devel-patches xemacs-gnats xemacs-mailmaint xemacs-mailmaint-admin xemacs-mailmaint-bounces xemacs-mailmaint-confirm xemacs-mailmaint-join xemacs-mailmaint-leave xemacs-mailmaint-mailman xemacs-mailmaint-owner xemacs-mailmaint-request xemacs-mailmaint-subscribe xemacs-mailmaint-unsubscribe xemacs-mirrors xemacs-mirrors-admin xemacs-mirrors-bounces xemacs-mirrors-confirm xemacs-mirrors-join xemacs-mirrors-leave xemacs-mirrors-owner xemacs-mirrors-request xemacs-mirrors-subscribe xemacs-mirrors-unsubscribe xemacs-mule xemacs-mule-admin xemacs-mule-archive xemacs-mule-bounces xemacs-mule-confirm xemacs-mule-join xemacs-mule-leave xemacs-mule-mailman xemacs-mule-owner xemacs-mule-request xemacs-mule-subscribe xemacs-mule-unsubscribe xemacs-news xemacs-news-admin xemacs-news-archive xemacs-news-bounces xemacs-news-confirm xemacs-news-join xemacs-news-leave xemacs-news-mailman xemacs-news-owner xemacs-news-request xemacs-news-subscribe xemacs-news-unsubscribe xemacs-nt xemacs-nt-admin xemacs-nt-request xemacs-patches xemacs-patches-admin xemacs-patches-archive xemacs-patches-bounces xemacs-patches-confirm xemacs-patches-join xemacs-patches-leave xemacs-patches-mailman xemacs-patches-owner xemacs-patches-request xemacs-patches-subscribe xemacs-patches-unsubscribe xemacs-request xemacs-review xemacs-review-admin xemacs-review-archive xemacs-review-bounces xemacs-review-confirm xemacs-review-join xemacs-review-leave xemacs-review-mailman xemacs-review-owner xemacs-review-request xemacs-review-subscribe xemacs-review-unsubscribe xemacs-test xemacs-test-admin xemacs-test-archive xemacs-test-bounces xemacs-test-confirm xemacs-test-join xemacs-test-leave xemacs-test-mailman xemacs-test-owner xemacs-test-request xemacs-test-subscribe xemacs-test-unsubscribe xemacs-users-ja xemacs-users-ja-admin xemacs-users-ja-archive xemacs-users-ja-bounces xemacs-users-ja-confirm xemacs-users-ja-join xemacs-users-ja-leave xemacs-users-ja-mailman xemacs-users-ja-owner xemacs-users-ja-request xemacs-users-ja-subscribe xemacs-users-ja-unsubscribe xemacs-users-ru xemacs-users-ru-admin xemacs-users-ru-archive xemacs-users-ru-bounces xemacs-users-ru-confirm xemacs-users-ru-join xemacs-users-ru-leave xemacs-users-ru-mailman xemacs-users-ru-owner xemacs-users-ru-request xemacs-users-ru-subscribe xemacs-users-ru-unsubscribe xemacs-webmaint xemacs-webmaint-admin xemacs-webmaint-bounces xemacs-webmaint-confirm xemacs-webmaint-join xemacs-webmaint-leave xemacs-webmaint-mailman xemacs-webmaint-owner xemacs-webmaint-request xemacs-webmaint-subscribe xemacs-webmaint-unsubscribe xemacs-winnt xemacs-winnt-admin xemacs-winnt-archive xemacs-winnt-bounces xemacs-winnt-confirm xemacs-winnt-join xemacs-winnt-leave xemacs-winnt-mailman xemacs-winnt-owner xemacs-winnt-request xemacs-winnt-subscribe xemacs-winnt-unsubscribe xlib-bugs xlib-discuss xlib-maintainer xlib-patches xslt-process-bugs xslt-process-discuss xslt-process-maintainer xslt-process-patches xwem-bugs xwem-discuss xwem-maintainer xwem-patches zenirc-bugs zenirc-discuss zenirc-maintainer zenirc-patches ======================================================================= List 2 - @tux.org [no explicit domain] or @xemacs.org names in the alias definitions ======================================================================= adrian andy bugs cvs-manager-archive jason majordomo-owner owner-w3-announce owner-w3-beta owner-w3-bugs owner-w3-dev stephen xemacs-admin xemacs-beta xemacs-buildreports xemacs-buildreports-admin xemacs-buildreports-request xemacs-crashes xemacs-mailmaint xemacs-mailmaint xemacs-news xemacs-news-request xemacs-users-ru-archive xemacs-webmaint xemacs-winnt xemacs-winnt-admin xemacs-winnt-request xemacweb ad...@xe... aid...@xe... an...@xe... di...@xe... j_c...@xe... ky...@xe... ma...@xe... mik...@xe... os...@xe... ov...@xe... si...@xe... st...@xe... st...@xe... tom...@xe... vi...@xe... w3...@xe... wm...@xe... xem...@xe... xem...@xe... yo...@xe... NOTE: adrian: /etc/passwd jason: /etc/passwd viteno: /etc/passwd wmperry: /etc/passwd xemacweb: /etc/passwd aidan.kehoe: NOT FOUND andy: NOT FOUND didier: NOT FOUND j_colman: NOT FOUND kyle: NOT FOUND matsl: NOT FOUND mike.sperber: NOT FOUND oscar: NOT FOUND ovidiu: NOT FOUND simon: NOT FOUND stephen: NOT FOUND steve: NOT FOUND tomohiko.morioka: NOT FOUND yoshiki: NOT FOUND bugs: /etc/mail/aliases-xemacs cvs-manager-archive: /etc/mail/aliases-xemacs majordomo-owner: /etc/mail/aliases-xemacs owner-w3-announce: /etc/mail/aliases-xemacs owner-w3-beta: /etc/mail/aliases-xemacs owner-w3-bugs: /etc/mail/aliases-xemacs owner-w3-dev: /etc/mail/aliases-xemacs w3-beta: /etc/mail/aliases-xemacs xemacs-admin: /etc/mail/aliases-xemacs xemacs-beta: /etc/mail/aliases-xemacs xemacs-buildreports-admin: /etc/mail/aliases-xemacs xemacs-buildreports-request: /etc/mail/aliases-xemacs xemacs-buildreports: /etc/mail/aliases-xemacs xemacs-crashes: /etc/mail/aliases-xemacs xemacs-mailmaint: /etc/mail/aliases-xemacs xemacs-news-request: /etc/mail/aliases-xemacs xemacs-news: /etc/mail/aliases-xemacs xemacs-patches: /etc/mail/aliases-xemacs xemacs-users-ru-archive: /etc/mail/aliases-xemacs xemacs-webmaint: /etc/mail/aliases-xemacs xemacs-winnt-admin: /etc/mail/aliases-xemacs xemacs-winnt-request: /etc/mail/aliases-xemacs xemacs-winnt: /etc/mail/aliases-xemacs ======================================================================= -- /*********************************************************************\ ** ** Joe Yao js...@tu... - Joseph S. D. Yao ** \*********************************************************************/ |
|
From: Fredrik N. <fc...@no...> - 2005-07-05 20:01:43
|
Ken Manheimer <ken...@gm...> writes: > In fact, for personal, day-to-day uses like journal entries and > such, i see symmetric encryption ... as being the default mode - > key-pair being somewhat heavyweight, ideally having a difficult > passphrase and choice restricted to only established keys. Symmetric encryption may be best for this sort of thing: it's not that public key is "better," but serves a different purpose. It depends upon whether you expect to have the same person encrypting and decrypting the data, or you expect others to decrypt what one has encrypted. For the first you just need a passphrase, for the second you need key distribution. From the sound of your application, symmetric would probably be the way to go, I'd think. > - whether i've missed something, and i can do symmetric-key > pgp/gpg encryption with mailcrypt without major contortions Alas, I've not gotten around to analyzing mailcrypt myself, so can't answer this. > - if not, whether it's so hard on purpose, and if so, why. I wouldn't think it's made hard on purpose, just it didn't fit the original intent (sending and receiving email) too well. > - If it is hard, but not on purpose, would any of you be willing to work > with me to make it easier to do symmetric-key encryption? (the > machinery would be pretty trivial, but keeping consistent with > existing mailcrypt stuff would take more attention.) I've no time for such a project right now, sorry! /Fredrik +----------------------------------------------------------------+ | Symeon | Fredrik Noon, Senior Software Engineer | | fc...@no... | Hifn, Inc. www.hifn.com | | www.noon.org | fn...@hi... +1 408 399 3630 | |-------------------+--------------------------------------------| | pgp key: <http://noon.org/keys/pgpkey.txt> 7840AC55 | +----------------------------------------------------------------+ =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken Manheimer <ken...@gm...> writes: > In fact, for personal, day-to-day uses like journal entries and > such, i see symmetric encryption ... as being the default mode - > key-pair being somewhat heavyweight, ideally having a difficult > passphrase and choice restricted to only established keys. Symmetric encryption may be best for this sort of thing: it's not that public key is "better," but serves a different purpose. It depends upon whether you expect to have the same person encrypting and decrypting the data, or you expect others to decrypt what one has encrypted. For the first you just need a passphrase, for the second you need key distribution. From the sound of your application, symmetric would probably be the way to go, I'd think. > - whether i've missed something, and i can do symmetric-key > pgp/gpg encryption with mailcrypt without major contortions Alas, I've not gotten around to analyzing mailcrypt myself, so can't answer this. > - if not, whether it's so hard on purpose, and if so, why. I wouldn't think it's made hard on purpose, just it didn't fit the original intent (sending and receiving email) too well. > - If it is hard, but not on purpose, would any of you be willing to work > with me to make it easier to do symmetric-key encryption? (the > machinery would be pretty trivial, but keeping consistent with > existing mailcrypt stuff would take more attention.) I've no time for such a project right now, sorry! /Fredrik +----------------------------------------------------------------+ | Symeon | Fredrik Noon, Senior Software Engineer | | fc...@no... | Hifn, Inc. www.hifn.com | | www.noon.org | fn...@hi... +1 408 399 3630 | |-------------------+--------------------------------------------| | pgp key: <http://noon.org/keys/pgpkey.txt> 7840AC55 | +----------------------------------------------------------------+ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Cygwin) iD8DBQFCyuchAi4MWHhArFURAh3NAKC5urvcAPdsAQXUcJyMhRdRDqzHCACgpMyQ M/357gQYMtDVsEWSJt7D1eg=3D =3DqVM7 =2D----END PGP SIGNATURE----- |
|
From: Ken M. <ken...@gm...> - 2005-07-05 18:12:20
|
Hi, all. Looks like activity in this project is pretty light, but i'm hoping some of the folks knowledgable about mailcrypt's design are reachable, and can give me some guidance. I'm incorporating topic encryption into my emacs outliner, 'allout', and would like to include both symmetric (which maybe mailcrypt refers to as "conventional") and key-pair pgp/gpg modes. I'm a novice when it comes to public key encryption, and may be making things harder on myself than they need to be. In fact, for personal, day-to-day uses like journal entries and such, i see symmetric encryption (enhanced with key verification and hinting) as being the default mode - key-pair being somewhat heavyweight, ideally having a difficult passphrase and choice restricted to only established keys. It's quite possible that thinking is misguided, something suggested by the lack of provision, and even apparent obstacles, that mailcrypt facilities pose to doing symmetric encryption. Mailcrypt does provide nicely for symmetric *decryption*, which further leads me to suspect that the impedence against symmetric key encryption is a deliberate design choice. I could do symmetric encryption with crypt++, using mailcrypt for key-pair encryption and all decryption, but would love to not depend on both packages. First, though, i wanted to understand the situation better. So i'm asking: - whether i've missed something, and i can do symmetric-key pgp/gpg encryption with mailcrypt without major contortions - if not, whether it's so hard on purpose, and if so, why. - If it is hard, but not on purpose, would any of you be willing to work with me to make it easier to do symmetric-key encryption? (the machinery would be pretty trivial, but keeping consistent with existing mailcrypt stuff would take more attention.) Thanks for any responses! Ken Manheimer ken...@gm... |
|
From: <ne...@us...> - 2004-12-30 02:43:00
|
(see also: https://sourceforge.net/tracker/index.php?func=detail&aid=1093072&group_id=397&atid=300397 ) mc-verify-signature has a comment: ; We can't find a message signed in the default scheme. ; Step through all the schemes we know, trying to identify ; the applicable one by examining headers. I think this is a wrong approach. If the "header" doesnt exist in the current scheme, then we move to a scheme we don't have loaded. For instance, if I do (mc-setversion "gpg") and then C-c / v, mailcrypt craps out with "Symbol's value as variable is void: mc-pgp50-fetch-key". PGP50?? I'm trying to use GPG!! Additionally I get this same error when I try to verify a signature on an email that is not signed! So, while we're trying to loop through schemes, we're not doing it correctly. I think we shouldn't be trying to second guess the user. If we dont know know the user is trying to acomplish, then we should throw and error and say we're confused. Attached is a patch against the current CVS (12/29/04) that removes the loop across the schemes in mc-toplevel.el |
|
From: Brian W. <wa...@lo...> - 2004-12-15 07:03:32
|
> Is there any activity on mailcrypt maintenance? > > I see patches, and I see CVS commits about a year ago, and about 4 > weeks ago. But no emails on this list... :( While not dead, it *is* pretty slow around here these days. I need to make a 3.5.9 release to get everything in CVS out the door, but in general there hasn't been a lot of pressure to add features, so consequently there hasn't been a lot of work on new releases. > In particular, I would be interested if anybody has tested > the MIME patch that's available since March. > And if somebody looks at the bug tickets; i.e., if it's sensible to > open new ones. I haven't heard any reports on that one. My hunch is that MIME requires a bit more infrastructure that isn't common across MUA modes, so Mailcrypt is not in the greatest of positions to do a very good job. But I'm happy to be proven wrong. Please do file bug reports, I think far more people read them and find them useful than is evidenced by the peaceful quiet that fills the mailing list :). Even if they don't get fixed very quickly, they form a locus around which discussion and potential workarounds can accumulate. cheers, -Brian (of course, I would also welcome anybody who would like to help out with maintenance.. I still use mailcrypt on occasion but perhaps there is someone out there who is using it more frequently than I am who could be doing a better job with the project than I've been. Let me know.) |
|
From: Joachim S. <js...@ac...> - 2004-12-06 22:25:19
|
Hi, Is there any activity on mailcrypt maintenance? I see patches, and I see CVS commits about a year ago, and about 4 weeks ago. But no emails on this list... :( In particular, I would be interested if anybody has tested the MIME patch that's available since March. And if somebody looks at the bug tickets; i.e., if it's sensible to open new ones. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim The most exciting phrase to hear in science, the Rödermark, Germany one that heralds new discoveries, is not "Eureka!" <js...@ac...> (I found it!) but "That's funny..." [Isaac Asimov] |
|
From: Kevin B. <kb...@gm...> - 2004-03-09 11:46:55
|
Hi all, here I send you a patch for Mime support according to Rfc 3156 for Mailcrypt. *This is an incomplete alpha version!* The reason I mail it here is that I don't see when I will find the time to finish it. Maybe someone else does. It currently only works for Gnus. For other MUAs some changes to mc-toplev.el are necessary. I only tested gpg, interactions with Mutt and itself ;-) Some things that still need to be done or fixed: - add support MUAs other than Gnus - Bug if the Mime boundary in the header is not enclosed in quotes: a better regexp or a cond clause has to be used - when decrypting one superfluous newline is added between header and body - variables like mc-gpg-signed-begin-line have to be inserted for pgp too, or they have to be hardcoded or maybe something completely different - testing, testing, testing... If someone is willing to help, please let me know. Kevin -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 |
|
From: Julian B. <jc...@in...> - 2003-11-25 14:23:19
|
>I use gpg, so I set mc-default-scheme to "gpg". OK, ok, ok, sorry! I'm sure I read some documentation somewhere that made it look as if mc-default-scheme took a string rather than a symbol... |
|
From: Julian B. <jc...@in...> - 2003-11-25 13:55:33
|
I'm finding it impossible to get mailcrypt (3.5.8) to work with vm, and wonder if anybody can point to me the right FAQ... My base system is VM 6.92, XEmacs 21.4.13, but I've also tried it with a clean build of XEmacs 21.5.16 with VM 7.17. I use gpg, so I set mc-default-scheme to "gpg". Then when I do mc-decrypt from my VM summary buffer, I just get "decryption failed: gpg", with no other information anywhere that I can find. (From the command line, gpg deals with the message quite happily.) |
|
From: Kevin B. <kb...@gm...> - 2003-11-02 19:00:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, the subject says it. Please check it out and test it extensively so that we can fix bugs and include it in the next release. If you use gpg as backend (mc-fetch-key) uses the gpg --recv-key method to fetch keys. This means that you can only fetch keys by id. You can now also set (mc-gpg-always-fetch) to t in order to retrieve keys automatically. For those folks who wants to fetch keys with the finger protocol I ported the corresponding pgp function to the interactive function (mc-gpg-fetch-from-finger). Kevin - -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQE/pVQfMdSnPCFfnIcRAqzcAJ4rI21e6btQH8pljrKRT58gVDeCrACfZU0y C8kPrC4Hwpz7JhTDh/Goz0A= =Xcze -----END PGP SIGNATURE----- |
|
From: Kevin B. <kb...@gm...> - 2003-10-30 12:58:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Warner <wa...@lo...> writes: [localisation] > The "gpg:" lines are stderr and can appear in other languages, the [GNUPG:] > lines are status-fd and are never localized. The GPG distribution has a > DETAILS file that specifies the format of that IMPORT_RES line: one of them > is a count of brand new keys, one is a count of updated keys, etc. Very good point. I didn't know about that DETAILS file. This mechanism makes parsing the output even simpler. Thanks. I will try to change this in the weekend. > Kevin, do you have a sourceforge account? If you like, I'll add you to the > committers list so you can check this one in yourself. Thank you for the confidence. I created an account named "kbube". Kevin - -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQE/oQlUMdSnPCFfnIcRAg92AJ0XMew7X0wSuIachOmaDuz27n9BqwCdHafT eZBmUz0mV3ED5PTK0E7YIuY= =Dn/6 -----END PGP SIGNATURE----- |
|
From: Brian W. <wa...@lo...> - 2003-10-29 18:51:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin: thanks for the patch! It looks good. The only thing I'd suggest is using the statusbuffer to count the keys instead of parsing stderr (which is localized by gettext when the user has set LANG to something other than english). I'd need to check to see how older version of gpg behave, but the current one gives the following output for key processing (for a key that is already in the keyring): % gpg --status-fd 2 --recv-keys 0x03a5e108 gpg: requesting key 03A5E108 from hkp://subkeys.pgp.net [GNUPG:] IMPORT_OK 0 9DF03E983525486D544A1EF3FE4F5E7F03A5E108 gpg: key 03A5E108: "Brian Warner <wa...@lo...>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 [GNUPG:] IMPORT_RES 1 0 0 0 1 0 0 0 0 0 0 0 0 0 The "gpg:" lines are stderr and can appear in other languages, the [GNUPG:] lines are status-fd and are never localized. The GPG distribution has a DETAILS file that specifies the format of that IMPORT_RES line: one of them is a count of brand new keys, one is a count of updated keys, etc. Kevin, do you have a sourceforge account? If you like, I'll add you to the committers list so you can check this one in yourself. I haven't had much time for mailcrypt recently, but we've got a lot of good changes in CVS (like a fix to that long-standing non-ascii \201-inserting bug) and we're *way* overdue for a new release. I'll try to schedule a "mailcrypt day" next week and get 3.5.9 out. The only big pending item is a mild tmpfile race insecurity, which can be worked around by users telling mailcrypt to use ~/tmp/ instead of /tmp for temporary files (the stderr/status-fd output holders). The proper fix is to use make-temp-file instead of make-temp-name, which I haven't committed yet because maintaining emacs20/XEmacs compatibility turned out to involve much more work than I thought. I'm not sure I'll manage to get this part in before a release, but I'll give it a shot. (I might fall back to using make-temp-file if available, otherwise use the must-be-worked-around make-temp-name function). thanks! -Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/oAwM/k9efwOl4QgRAoxhAJ98n7in6+wlDeBfP89RFgJmDjEeHgCfejrZ F9O55rWMGFWCSXINVW2YEms= =lVl0 -----END PGP SIGNATURE----- |
|
From: Kevin B. <kb...@gm...> - 2003-10-26 15:34:56
|
Hi folks, here is another patch concerning gpg keyfetching. The whole thing is now integrated into the framework. Furthermore I added an interactive function mc-gpg-fetch-from-finger. This is just a ported version of the analogous pgp function with slight modifications. It is not possible to make this function the standard way to fetch keys as the format of the argument is completely different from the other fetching function. I consider this not a problem, as most people will only use this method from time to time. Please test this and apply it to CVS if you like it. Kevin -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 |
|
From: Kevin B. <bu...@ic...> - 2003-09-19 20:11:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 William L Anderson <ba...@ac...> writes: Hi, > Actually two questions: > > 1. Has there been any work done toward supporting GPG sigs as MIME > attachments? Right now verifying a MIME attached sig fails. There has been done some work by Felix Schlesinger. See the archive of this mailing list. I don't know how far the patch works. > [snip] > > Any suggestions are where to look or even where to start experimenting > with coding are appreciated. The first starting point is RFC 3156. Then you should maybe contact Felix. I am also willing to help writing an implementation. > > Bill Anderson > Kevin - -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQE/ar0hMdSnPCFfnIcRAqZcAJkB3PA0IKSgxKfkiY5e9mVvPq4SqgCgiTd0 Y5IuvwogLOZ8fBKQ9hl3faU= =NXXG -----END PGP SIGNATURE----- |
|
From: William L A. <ba...@ac...> - 2003-09-18 18:42:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually two questions: 1. Has there been any work done toward supporting GPG sigs as MIME attachments? Right now verifying a MIME attached sig fails. 2. Is there any interest in, or work done, to support X509 signed email? I know this is off-topic, but I really would like to keep using VM and Mailcrypt _and_ also handle my business e-mail. Any suggestions are where to look or even where to start experimenting with coding are appreciated. Bill Anderson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (MingW32) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/afuI1u2F7DlTaCERAj/+AJ9HJDnAKhAhzJpqvErJCoJ0pT0FdwCgtoTK K/xiGZorGXeREyKI6ML8Z64= =xuKs -----END PGP SIGNATURE----- |
|
From: Kevin B. <kb...@gm...> - 2003-09-15 16:50:53
|
-- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 |
|
From: Kevin B. <bu...@ic...> - 2003-09-12 18:42:29
|
Hi folks, here I send you a patch which introduces a new interactive function (mc-gpg-fetch-key) which makes it possible to fetch keys from a keyserver for those who use gnupg. Please test it and send me your comments and suggestions before I integrate the function in the menu and the other framework. The error handling is a bit, uhh, binary. Do you think it should be more verbose (e.g. report if keyserver is unreachable, key not found, etc.)? Kevin |
|
From: Kevin B. <kb...@gm...> - 2003-09-09 04:49:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Warner <wa...@lo...> writes: > I like it. Glad to hear this ;-) > Can the --recv-keys option accept arbitrary names? Or can it only > take hex keyids? If so, we should document that limitation heavily: none of > the other keyfetching code has it. It can only take hex keyids. For full names there exists the option - --search-keys, but with this you end up in a dialog which lets you select the desired one from the matching keys. Furthermore it works _only_ with real names not with ids. I guess using this instead of - --recv-key would introduce trouble with mc-gpg-always-fetch. How does pgp solve the problem? > If it succeeds, it should list the number of keys imported (although really > what would be useful is the full name that's attached to the key, so you can > check to see if you got the right one). The current patch should report the full name on success (I think this works only with one id right now, needs testing). > If it fails, perhaps we could just (message) the contents of > stderr-buf? Yes, I will do this. > thanks! > -Brian Kevin - -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQE/XDd6MdSnPCFfnIcRAp2vAJ9FktuUJs6eu9hvQdffIBnryZE5+gCfal1K X/X/bsi6lHgpnJdiQb2RIB8= =KQrr -----END PGP SIGNATURE----- |
|
From: Brian W. <wa...@lo...> - 2003-09-09 01:02:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > How does pgp solve the problem? The pgp key-fetching methods either use finger or do an HTTP fetch from a keyserver (which lets you search for arbitrary strings, just like their web interfaces provide). I think it then just imports every key that is returned. (it was written in an era of fewer keys). I don't if HKP lets you search on strings, but if it does allow email-address searches then maybe it'd be ok to just import all the matches. -Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/XPkG/k9efwOl4QgRAkOmAJ9BAdSl9DybzcO2ovkpZGKsxHjDSgCfbX1T T2JH4AEL+yoxA/CduEBEJY8= =xjxT -----END PGP SIGNATURE----- |
|
From: Brian W. <wa...@lo...> - 2003-09-08 06:53:24
|
> the attached patch replaces the dummy function (mc-gpg-fetch-key) by a > real one. This makes it possible for Gnupg users to fetch keys from > external servers. I like it. Can the --recv-keys option accept arbitrary names? Or can it only take hex keyids? If so, we should document that limitation heavily: none of the other keyfetching code has it. > The error handling is a bit, uh, binary. Do you think it needs to be > more verbose (e.a. report the reason for failures)? I left this because > if one has really trouble there exists the possibility to have a look at > the gpg error buffer. If it succeeds, it should list the number of keys imported (although really what would be useful is the full name that's attached to the key, so you can check to see if you got the right one). If it fails, perhaps we could just (message) the contents of stderr-buf? Worst case we could emit a message that suggests which buffer to look at for the error messages. Also remember that the stderr buf is normally deleted after the operation completes (I think). thanks! -Brian |
|
From: nega <neg...@ya...> - 2003-09-08 03:02:39
|
Guess I should read all of my email first. :) Kevin, I havent exactly stressedit but it works fine for me. --- Kevin Bube <kb...@gm...> wrote: > Hi folks, > > the attached patch replaces the dummy function (mc-gpg-fetch-key) by > a > real one. This makes it possible for Gnupg users to fetch keys from > external servers. > > Please have a look, test this and send me comments before I start > integrating the function into the menu and the other framework. > > The error handling is a bit, uh, binary. Do you think it needs to be > more verbose (e.a. report the reason for failures)? I left this > because > if one has really trouble there exists the possibility to have a look > at > the gpg error buffer. > > Kevin > > > diff -Naur mailcrypt/mc-gpg.el mailcrypt.fetchonly/mc-gpg.el > --- mailcrypt/mc-gpg.el Thu Aug 14 12:41:31 2003 > +++ mailcrypt.fetchonly/mc-gpg.el Thu Sep 4 16:56:26 2003 > @@ -1283,14 +1283,46 @@ > "*If t, always attempt to fetch missing keys, or never fetch if > 'never.") > > -(defun mc-gpg-fetch-key (&optional id) > +(defvar mc-gpg-keyserver 'nil > + "*Keyserver to query for missing keys. If nil let GPG use its > default.") > + > + > +(defun mc-gpg-fetch-key-parser (stdoutbuf stderrbuf statusbuf rc > parserdata) > + (let (result) > + (save-excursion > + (set-buffer stderrbuf) > + (goto-char (point-min)) > + > + (mc-gpg-debug-print > + (format "(mc-gpg-fetch-key-parser (stdoutbuf=%s stderrbuf=%s > statusbuf=%s rc=%s" stdoutbuf stderrbuf statusbuf rc)) > + > + > + (if (search-forward "Total number processed: " nil t) > + ;; success > + (progn > + (re-search-backward "\".*\"") > + (setq result (list nil t (match-string 0)))) > + ;; failure > + (setq result (list nil nil nil)))) > + )) > + > +(defun mc-gpg-fetch-key (id) > "Attempt to fetch a key for addition to GPG keyring. > Interactively, > -prompt for string matching key to fetch. > +prompt for string matching key to fetch." > + (interactive "sKey-ID: ") > + > + (let ((buffer (get-buffer-create mc-buffer-name)) > + args result) > + (setq args (list "--recv-keys" id)) > + (if mc-gpg-keyserver > + (setq args (append (list "--keyserver" mc-gpg-keyserver args)))) > > -This function is not yet implemented. The GPG documentation suggests > a simple > -keyserver protocol, but as far as I know it has not yet been > implemented > -anywhere." > + (setq result (mc-gpg-process-region 1 1 nil mc-gpg-path args > + 'mc-gpg-fetch-key-parser buffer)) > > - (error "Key fetching not yet implemented")) > + (if (car result) > + (message "Imported key %s: %s" id (cdr result)) > + (error "Couldn't fetch key %s" id)) > + )) > > ;;}}} > > > > -- > publickey: http://www.icbm.de/~bube/publickey.txt > fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: nega <neg...@ya...> - 2003-09-08 03:00:59
|
Hey all- Here's a small patch that I did in '01 to use GPG instead of PGP. I *think* it totally replaces the mc-pgp functions related to key fetching with mc-gpg functions (IE: it rips out pgp support), but I'm not sure. It also updates mailcrypt.el with the appropriate function names. Maybe it'll give you some ideas. --- Kevin Bube <kb...@gm...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Richardson <mc...@sa...> writes: > > > Can't you just reuse the whole pgp2 interface that talks to > finger and > > to the key servers? You just need to call "gpg --import" instead of > "pgp" > > to suck the key in at the end of the dialogue. > > In the finger case this is exactly what I planned to do ;-) But for > the > keyserver case I agree with Simon and think that it is better to let > gpg > do all the error handling and stuff like that. It would unnecessarily > blow > our code if we write an own function for every possible protocol. To > finger > I would make an exception because it is widely used and up to now (to > my > knowledge) not directly supported by gpg. > > I hope within a few weeks I can send some results here. > > Kevin > > - -- > publickey: http://www.icbm.de/~bube/publickey.txt > fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > Comment: Processed by Mailcrypt 3.5.8+ > <http://mailcrypt.sourceforge.net/> > > iD8DBQE/Tgx6MdSnPCFfnIcRAiGSAJ9AzrwOgq2fR9BCGaU+v9XxmQQIlACfSiEg > R8Eq76LdI0b59+gVZ28bZN8= > =zzTA > -----END PGP SIGNATURE----- > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > mailcrypt-bugs mailing list > mai...@li... > https://lists.sourceforge.net/lists/listinfo/mailcrypt-bugs __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Kevin B. <kb...@gm...> - 2003-09-05 07:55:43
|
Hi folks, the attached patch replaces the dummy function (mc-gpg-fetch-key) by a real one. This makes it possible for Gnupg users to fetch keys from external servers. Please have a look, test this and send me comments before I start integrating the function into the menu and the other framework. The error handling is a bit, uh, binary. Do you think it needs to be more verbose (e.a. report the reason for failures)? I left this because if one has really trouble there exists the possibility to have a look at the gpg error buffer. Kevin |
|
From: Kevin B. <kb...@gm...> - 2003-08-28 14:07:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Richardson <mc...@sa...> writes: > Can't you just reuse the whole pgp2 interface that talks to finger and > to the key servers? You just need to call "gpg --import" instead of "pgp" > to suck the key in at the end of the dialogue. In the finger case this is exactly what I planned to do ;-) But for the keyserver case I agree with Simon and think that it is better to let gpg do all the error handling and stuff like that. It would unnecessarily blow our code if we write an own function for every possible protocol. To finger I would make an exception because it is widely used and up to now (to my knowledge) not directly supported by gpg. I hope within a few weeks I can send some results here. Kevin - -- publickey: http://www.icbm.de/~bube/publickey.txt fingerprint: 607B 39BC C9E9 0F5E EF7F 4557 31D4 A73C 215F 9C87 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQE/Tgx6MdSnPCFfnIcRAiGSAJ9AzrwOgq2fR9BCGaU+v9XxmQQIlACfSiEg R8Eq76LdI0b59+gVZ28bZN8= =zzTA -----END PGP SIGNATURE----- |
|
From: Michael R. <mc...@sa...> - 2003-08-28 13:42:16
|
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Kevin" == Kevin Bube <kb...@gm...> writes:
>> Will we still get finger as a way to get keys? We find that this is a
>> much more stable, much more obvious and way more scalable way to get
>> keys. No single point of failure, or place for guberment to coerce.
>>
Kevin> Maybe I will write an extra function for this. My problem is that
Kevin> time is a rare gift at the moment :-)
Can't you just reuse the whole pgp2 interface that talks to finger and
to the key servers? You just need to call "gpg --import" instead of "pgp"
to suck the key in at the end of the dialogue.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat
iQCVAwUBP04GnoqHRg3pndX9AQHsRAP/WD678i6RON5L+JuHDQ+6zBAT4mCGWk9D
5JNj2AChpJn4aaViTYDjxY4+Tu0SFYghxb2XKWPKPij8ZQXMuJnbN+VyrkYgLZZb
fc3Ol8efHpQLf06lrDvrg04eex9xFXOU1sxDPEw6PRfME5mBxuOdDGVYW5vV4SBH
vuBiZHajObU=
=Rpny
-----END PGP SIGNATURE-----
|
370 messages has been excluded from this view by a project administrator.
