unsubscribe me

Eduardo Sánchez e.sanchez@maximiles.com
Mon Mar 11 15:18:02 2002


Please unsuscribe me too.

> -----Mensaje original-----
> De: gnupg-users-admin@gnupg.org [mailto:gnupg-users-admin@gnupg.org]En
> nombre de McKerracher, Priscilla
> Enviado el: lunes, 11 de marzo de 2002 14:27
> Para: 'gnupg-users@gnupg.org'
> Asunto: unsubscribe me
>
>
> Please unsubscribe me.
>
> SIG Section Supervisor
> priscilla_mckerracher@jhuapl.edu
> Johns Hopkins University
> Applied Physics Laboratory
> Johns Hopkins Road
> Laurel, MD 20723
> 443-778-4474
>
> -----Original Message-----
> From: gnupg-users-request@gnupg.org
> [mailto:gnupg-users-request@gnupg.org]
> Sent: Sunday, March 10, 2002 6:06 AM
> To: gnupg-users@gnupg.org
> Subject: Gnupg-users digest, Vol 1 #549 - 8 msgs
>
>
> Send Gnupg-users mailing list submissions to
> 	gnupg-users@gnupg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.gnupg.org/mailman/listinfo/gnupg-users
> or, via email, send a message with subject or body 'help' to
> 	gnupg-users-request@gnupg.org
>
> You can reach the person managing the list at
> 	gnupg-users-admin@gnupg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnupg-users digest..."
>
>
> Today's Topics:
>
>    1. Re: missing documentation / rant (Oyvind A. Holm)
>    2. Re: blowfish in gnuPG 1.0.6 =? 256 bit (Marc Mutz)
>    3. Re: missing documentation / rant (Martin Blais)
>    4. Re: missing documentation / rant (Martin Blais)
>    5. Re: missing documentation / rant (Oyvind A. Holm)
>    6. Re: blowfish in gnuPG 1.0.6 =? 256 bit (Bob Mathews)
>    7. Announcement for OpenCDK (Timo Schulz)
>    8. Re: duplicate keyid survey results (Hironobu SUZUKI)
>
> --__--__--
>
> Message: 1
> Date: Sat, 9 Mar 2002 22:05:06 +0100 (CET)
> From: "Oyvind A. Holm" <sunny@sunbase.org>
> To: Martin Blais <blais@iro.umontreal.ca>
> cc: gnupg-users@gnupg.org
> Subject: Re: missing documentation / rant
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2002-03-09 15:02 Martin Blais wrote:
> > another big one (for me and other friends): the default behaviour for
> > "gpg file.gpg" is to decrypt to a file "file", and apart from asking
> > for the passphrase it doesn't say it has output the PLAINTEXT to a
> > FILE. the user that is not careful might forget or not know that is
> > unencrypted document lies in the filesystem! that is a big problem!
> > IMHO that should not be the default behaviour, the default, just as
> > for input, should be that it outputs to stdout, just like --decrypt
> > does, and that using --decrypt should output to a file (plus we
> > should get a message that says so, every functionality that write
> > unencrypted data to the filesystem should warn the user).
>
> This can easily be avoided by using
>
>     gpg <file.gpg
>
> The output will then be sent to stdout. IMHO the current behaviour of
> GnuPG is correct. When specifying a file directly, GPG behaves the
> similar way -- creating a file. This is the de facto way of doing
> things in UNIX and I don't think that should be changed. Another
> question is whether it should be changed on DOSish systems, as the
> stdin/stdout thing is pretty unfamiliar in the DOS (aka windows) world.
> But then it's a Bad Thing to make a program work differently in
> different environments. That would lead to more trouble than it's
> worth.
>
> Talking about stdin/stdout... I have to mention the horrible behaviour
> by PGP 6.x. When I get encrypted mail, most of the time as armoured
> text, I mark the text in my editor (joe) and filter it through GnuPG.
> Works fine. One day I tried doing the same using PGP. It read from
> stdin, but it did not send the output to stdout, instead it created a
> file called "stdin" or something like that in the current directory
> where i started my mail program. I must say I was shocked by this. I'd
> _never_ think such a widespread program could have serious flaws like
> this. If i remember correctly, one have to specify an option (-f or
> something) to make PGP use stdin/stdout, but I still call it a flaw. If
> it doesn't print to stdout, it should neither read from stdin. Indeed
> PGP acts like a strange bird in an UNIX environment.
>
> Regards,
> =D8yvind
>
> +-------------------------------------------------------------------+
> | OpenPGP: 0x629022EB 2002-02-24 =D8yvind A. Holm <sunny@sunbase.org> |
> | Fingerprint: DBE9 8D44 67F7 42AC 2CA1  7651 724E 9D53 6290 22EB   |
> +------------- Nostalgien er ikke hva den engang var. --------------+
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iD8DBQE8injqck6dU2KQIusRAtKpAJ9gfO/XcS9dXtKsImQyHN+TBwqNPACgpU7q
> BPIxa3uH1MeC0TOxlY77ii8=3D
> =3Ds1Ae
> -----END PGP SIGNATURE-----
>
>
>
> --__--__--
>
> Message: 2
> From: Marc Mutz <Marc.Mutz@uni-bielefeld.de>
> To: uwe puchta <u_p@lycos.de>,
>  gnupg-users@gnupg.org
> Subject: Re: blowfish in gnuPG 1.0.6 =? 256 bit
> Date: Sat, 9 Mar 2002 22:28:08 +0100
> Organization: Bielefeld University - Department of Physics
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 09 March 2002 12:55, uwe puchta wrote:
> > just a question out of curiosity:
> > what's the key size for Blowfish encryption?
> > is it 256 bit?
> > ... for both cipher-algo and s2k-cipher-algo
> > (if defined so in the options file or at the
> > command line)
> <snip>
>
> http://www.counterpane.com/blowfish.html
>
> - --=20
> Marc Mutz <mutz@kde.org>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8in5o3oWD+L2/6DgRAkvZAJwKaB7fZVJef25joMMlFlzFrvdyUACgjxzI
> YSMEWqB7kWW1Zc4idqMXsNw=3D
> =3DnndK
> -----END PGP SIGNATURE-----
>
>
>
> --__--__--
>
> Message: 3
> From: Martin Blais <blais@iro.umontreal.ca>
> To: Werner Koch <wk@gnupg.org>
> Subject: Re: missing documentation / rant
> Date: Sat, 9 Mar 2002 16:39:46 -0500
> Cc: gnupg-users@gnupg.org
>
> On Saturday 09 March 2002 16:03, Werner Koch wrote:
> > On Sat, 9 Mar 2002 15:02:23 -0500, Martin Blais said:
> > > these options don't know show up in the man page. someone really ought
> to
> > > do the grunt work of cross-checking the man page
> documentation with the
> > > actual
> >
> > There are reasons for this.  --dump-options is for example also not
> > listed in the man page.  But hey, you have the source, so where is the
> > problem.
>
> there is no real problem, one of the users (me) is confused, and
> is making
> comments to the developers in order to allow them to improve the
> documentation of their software.
>
> i'd like to know what they are? it would be nice if there was a clear
> separation between options that are shown by --help and those that aren't
> and
> that are explained in the man page and manual (perhaps dub them "extended"
> or
> "private" options?).  in any case, either the manual or
> documentation should
>
> reflect all options, right?
>
> i understand that documentation is difficult to keep up-to-date by a
> distributed team (and the handbook is actually quite impressive), but this
> is
> indeed a 1.0 release and for such an important release
> documentation should
> be polished... i wouldn't have bothered making comments for a development
> release, because i understand that. my own system is that i make it a
> requirement to releasing, i.e. i don't allow myself to release until i've
> updated the docs. if i want to release something i have to bite
> the bullet
> and slave at the docs.
>
> (and besides, sorry, but looking at the source doesn't qualify as
> documentation, which is what my comments are about. the beauty of oss is
> that
> i can if i want to (especially to make modifications), but that
> doesn't mean
>
> that all users of gpg SHOULD have to become acquainted with the source to
> find out what an option listed in --help is meant to do. i'm sure you'll
> agree with this.)
>
>
> > > fixed (and if so, why doesn't it do that by itself?).
> besides, i cannot
> > > figure out how to use check-trustdb, all i get is output like this:
> >
> > So don't use it.  As said, there is a reason that it is not listed.
>
> well, it IS indeed listed in "gpg --help".  i didn't mean to use
> it, i meant
>
> to understand what it does because it was listed, and is not
> documented, and
>
> that is why i was trying it. if i'm not meant to use it, then the
> problem is
>
> that it was listed.
>
>
> > BTW, the next version has it mentioned because this command has a real
> > use then.
> >
> > > also of interest:
> > >     --allow-secret-key-import
> > >
> > > is not mentioned on the output of "gpg --help". i'm sure
> there are many
> >
> > If you try to import a secret key, a messge is printed, telling you to
> > use this option.  Anyway, this option is just a temporary hack and not
> > anymore needed in 1.0.6d.  Printing all 202 commands and options with
>
> cool.
>
>
> > --help make no sense, it is just too much and can't probably not be
> > understood without a more verbose description.  Anyway, recent
> > versions do print:
> >
> >       --photo-viewer               Set command line to view Photo IDs
> >    -N, --notation-data NAME=VALUE   use this notation data
> >
>
> >   (See the man page for a complete listing of all commands and options)
>
> that's exactly my point!  is at least the man page complete? options that
> are
> listed in --help should at least also be in the man page. the opposite is
> not
> necessarily true, and some kind of grouping to acknowledge that is a nice
> way
> to let the user understand this (something like "basic options" and
> "extended
> options").
>
>
>
> > There is nothing important missing, some things are maintainer only.
> > If you or the people attracted by encryption real want to get into it,
> > use the source.
>
> those maintainer-only options should then not be visible to the
> user if he's
>
> not to use them. all i'm arguing for, is that the maintainer/for-debug
> options be somehow marked as such or not visible.
>
>
> > > another big one (for me and other friends): the default behaviour for
> > > "gpg file.gpg" is to decrypt to a file "file", and apart from
> asking for
> > > the passphrase it doesn't say it has output the PLAINTEXT to
> a FILE. the
> >
> > Which is the correct behaviour of a Unix tool.  Use --verbose to get
> > what you want.
>
> agreed, read on...
>
>
> > > lies in the filesystem!  that is a big problem!  IMHO that
> should not be
> > > the default behaviour, the default, just as for input, should
> be that it
> > > outputs to stdout, just like --decrypt does, and that using --decrypt
> > > should output
> >
> > A lot of tools do have this behaviour and it makes a lot of sense. IF
> > you want to have the output on stdout, send the input to stdin.
>
> i know i can use --decrypt and i do now (actually, you make me
> think, i'll
> try putting it in my options file).
>
> well, please consider that a default behaviour of writing plaintext files
> out
> to the filesystem is behaviour that does not foster trust in a
> program that
> is meant to provide data security for its user. i mean, there is a reason
> for
> that file to be encrypted in the first place. if i considered my
> filesystem
> permissions to be secure i probably wouldn't use encryption to store files
> on
> it.
>
> i have often forgotten to delete unencrypted files because of
> that (and even
>
> sometimes on my cd backups, which were recently robbed with the
> rest of the
> computing equipment. not a cool feeling. i agree that it is my
> fault because
>
> i misused gpg, but food for thought anyway. IMHO plaintext should only be
> written to files on request. consider it a security feature, and
> not a minor
>
> one---the user is less likely to make the mistake of decrypting to disk.)
>
> thanks for your quick answer.
> cheers,
>
>
> --__--__--
>
> Message: 4
> From: Martin Blais <blais@iro.umontreal.ca>
> To: "Oyvind A. Holm" <sunny@sunbase.org>
> Subject: Re: missing documentation / rant
> Date: Sat, 9 Mar 2002 16:53:28 -0500
> Cc: gnupg-users@gnupg.org
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 09 March 2002 16:05, Oyvind A. Holm wrote:
> > On 2002-03-09 15:02 Martin Blais wrote:
> > question is whether it should be changed on DOSish systems, as the
> > stdin/stdout thing is pretty unfamiliar in the DOS (aka windows) world.
> > But then it's a Bad Thing to make a program work differently in
> > different environments. That would lead to more trouble than it's
> > worth.
>
> good point, so i guess it cannot be changed.
>
> perhaps an option to alter that behaviour would be cool. that option could
> be
> put in the user's options file to get that behaviour.
>
> just my 2cents.
> thx again,
> -----BEGIN PGP SIGNATURE-----
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjyKhFwACgkQq2PmC9F3Xx3UBACfYWoQti6Qhn/RoAxZ2jSCLMAo
> axoAn35J/lP6Wt+P++ZDAcc48NK8STx8
> =qCY2
> -----END PGP SIGNATURE-----
>
>
> --__--__--
>
> Message: 5
> Date: Sat, 9 Mar 2002 23:30:32 +0100 (CET)
> From: "Oyvind A. Holm" <sunny@sunbase.org>
> To: Martin Blais <blais@iro.umontreal.ca>
> cc: gnupg-users@gnupg.org
> Subject: Re: missing documentation / rant
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2002-03-09 16:53-0500 Martin Blais wrote:
> > On 2002-03-09 22:05:06+0100, Oyvind A. Holm wrote:
> > > Another question is whether it should be changed on DOSish systems,
> > > as the stdin/stdout thing is pretty unfamiliar in the DOS (aka
> > > windows) world. But then it's a Bad Thing to make a program work
> > > differently in different environments. That would lead to more
> > > trouble than it's worth.
> >
> > good point, so i guess it cannot be changed.
> >
> > perhaps an option to alter that behaviour would be cool. that option
> > could be put in the user's options file to get that behaviour.
>
> That seems like a good idea. Having an "always-stdout" option would be
> a good thing to have, especially when thinking of how hard it is to
> completely erase data from hard disks once it's written. After all,
> it's easy to redirect the output to a file. I still think the current
> behaviour should be the default, but I see no drawback in having an
> configuration option to achieve this behaviour.
>
> Regards,
> =D8yvind
>
> +-------------------------------------------------------------------+
> | OpenPGP: 0x629022EB 2002-02-24 =D8yvind A. Holm <sunny@sunbase.org> |
> | Fingerprint: DBE9 8D44 67F7 42AC 2CA1  7651 724E 9D53 6290 22EB   |
> +----------- 2 + 2 =3D 5 for extremely large values of 2. ------------+
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iD8DBQE8iozTck6dU2KQIusRArY+AJ96aTJgFkdinstjIGrHTVr8xVpEygCfW5vi
> IRrTZmSXdnJ2DKSDp/sXVI8=3D
> =3DCiW9
> -----END PGP SIGNATURE-----
>
>
>
> --__--__--
>
> Message: 6
> From: Bob Mathews <bobmathews@mindspring.com>
> To: Marc Mutz <Marc.Mutz@uni-bielefeld.de>,
> 	uwe puchta <u_p@lycos.de>, gnupg-users@gnupg.org
> Subject: Re: blowfish in gnuPG 1.0.6 =? 256 bit
> Date: Sat, 9 Mar 2002 14:36:45 -0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 09 March 2002 01:28 pm, Marc Mutz wrote:
> > On Saturday 09 March 2002 12:55, uwe puchta wrote:
> > > just a question out of curiosity:
> > > what's the key size for Blowfish encryption?
> > > is it 256 bit?
> > > ... for both cipher-algo and s2k-cipher-algo
> > > (if defined so in the options file or at the
> > > command line)
> >
> > <snip>
> >
> > http://www.counterpane.com/blowfish.html
>
> That page says that blowfish has a variable length key. However, according
> to
> RFC2440, OpenPGP uses blowfish with a 128-bit key. That applies
> to both the
> - --cipher-algo and --s2k-cipher-algo options.
>
>  -bob mathews
>
> -----BEGIN PGP SIGNATURE-----
> Comment: What's this? http://bobmathews.home.mindspring.com/bob/
>
> iD8DBQE8io5/PgDecCrBEpcRAvZyAJ9mepDoScVoV1vvpUvKvcFAhf8JVwCeIfCh
> 4qakEveOZBnTDcGg3j+pSOc=
> =RvAN
> -----END PGP SIGNATURE-----
>
>
> --__--__--
>
> Message: 7
> Date: Sun, 10 Mar 2002 00:22:24 +0100
> From: Timo Schulz <twoaday@freakmail.de>
> To: GnuPG Users <gnupg-users@gnupg.org>
> Subject: Announcement for OpenCDK
> Reply-To: twoaday@freakmail.de
>
>
> Hi,
>
> I decided to create a library which implements basic parts
> of the RFC2440 (OpenPGP) message format. This library will
> be no replacement for any real OpenPGP application like PGP
> or GPG. The goals of the library are to provide an API for
> parsing packets and to work with OpenPGP keys.
>
> There is also some code for signing, verification, encrypt
> and decrypt, but this is only partly done.
>
> Some of the code based on GPG and for all crypto functions
> we referring to the libgcrypt library. This library is responsible
> for secure memory, random generation and other sentensive parts.
>
> Currently the library is work on progress, but for the people
> who want to take a look at it can find the source on this webpage:
> http://www.winpt.org/opencdk.html
>
> Of course the whole project is available under the terms of the
> GNU General Public License.
>
>
>         Timo
>
>
>
>
>
> --__--__--
>
> Message: 8
> From: Hironobu SUZUKI <hironobu@h2np.net>
> To: David Shaw <dshaw@jabberwocky.com>
> cc: pgp-keyserver-folk@flame.org, gnupg-users@gnupg.org
> Subject: Re: duplicate keyid survey results
> Date: Sun, 10 Mar 2002 10:23:55 +0900
>
>
> I tried to send my e-mail to dshaw@jabberwocky.com from my two mail
> addresses, hironobu@h2np.net and hironobu@pgp.nic.ad.jp, but all of my
> e-mails were rejected.
>
> Please let me know another your e-mail address which I can send one.
>
> And I'm sorry for ML readers.
>
> Best Regards,
>
>
> --
> Hironobu SUZUKI
> E-Mail: hironobu@h2np.net
> URL: http://h2np.net
>
>
>
>
> --__--__--
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
> End of Gnupg-users Digest
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users