|
Bugzilla – Full Text Bug Listing |
| Summary: | some gpg issues | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Olli Artemjev <grey-olli> |
| Component: | Other | Assignee: | Klaus Singvogel <kssingvo> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Minor | ||
| Priority: | P4 - Low | CC: | grey-olli |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | SuSE Linux 10.0 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | debug.log from the command: 'strace gpg --debug-all --gen-key 2>debug.log' + mine gpg.conf | ||
Created attachment 70317 [details]
debug.log from the command: 'strace gpg --debug-all --gen-key 2>debug.log' + mine gpg.conf
attaching test case for these "invalid item `S2' in preference string" cases.
Regarding the first part (secure memory): You can find this in /usr/share/doc/packages/README.SuSE: The gpg binary is installed setuid root by default. This allows GnuPG to use mlock() to prevent the pages that contain your secret key to be swapped out to disk. SUSE has moved the allocation of the secure memory to an earlier stage in GnuPG, so that it happens before option processing. After this, gpg drops all privileges, so this setup is safe. This patch works AFAIK only under Linux. So, you might not find it upstream (at gnupg.org), but I'm not sure, I inherited gpg later. For the later parts, I'm not very familiar with. Therefore I asked back at gnupg-devel mailing list. I added you (reporter) into CC: About secmem: Okay.. seems the man in SuSE should contain note to /usr/share/doc/packages/gpg*/README.SuSE . Right? ----------------- [ 01:17:20, olli@skylab, ~ ] $ ls -ld /usr/share/doc/packages/gpg* drwxr-xr-x 2 root root 4096 2006-01-05 03:06 /usr/share/doc/packages/gpg drwxr-xr-x 2 root root 142 2006-01-05 03:23 /usr/share/doc/packages/gpg2 drwxr-xr-x 2 root root 98 2006-01-05 03:38 /usr/share/doc/packages/gpgme ----------------- [ 01:17:45, olli@skylab, ~ ] $ find /usr/share/doc/packages/gpg* -type f -iname readme.suse /usr/share/doc/packages/gpg/README.SuSE ----------------- [ 01:18:18, olli@skylab, ~ ] $ Somthing like: 'option require-sec-mem is obsolette w/ SuSE, see /usr/sha...'. Agree? BTW: what was a reason to move that? Just curious. %) After that movement I'm not sure of what type of memory is used currently. And I can't get to know that easilly since option require-secmem that allows to know that exactly is not applicable, as you noted above. I may enable warning on insecure memory.. but would that work or it's also out of business? I'm not really care much about that having encrypted /home and encrypted swap. But anyway. ?-) As about mailing list - thanks, I'd be glad if replies 'll 've me in CC too. The manual page (man 1 gpg) is not very transparent.. 'll look other dox being onroad. %) And more stuff around that (relating to the mailing list mails): ----cut----- On Mon, 27 Feb 2006, Malte Gell wrote: > That "cert-digest-algo SHA512" doesn╢t work with DSA keys is obvious, > RSA keys allow to chose any hash algo. ----cut----- That should be noted in the man, probably? And more: ----cut----- > The only error message reported is "gpg: invalid item `S2' in preference > string" and this smells like a typo in ~/.gnupg/gpg.conf rather than a > bug. > Olli invoked "grep s2k gpg.conf" which cannot tell the typo, because > according to the error message "S2" is the wrong value used somewhere. > > So, what does "grep S2 ~/.gnupg/gpg.conf" say? ----------------- [ 01:22:49, olli@skylab, ~/.gnupg ] $ grep S2 ~/.gnupg/gpg.conf cipher-algo AES256 s2k-cipher-algo AES256 ----------------- [ 01:23:06, olli@skylab, ~/.gnupg ] $ ----cut----- Now left only that s2-related thing in gpg.conf ----cut----- ----------------- [ 01:27:22, olli@skylab, ~ ] $ mv .gnupg/ .gnupg--- `.gnupg/' -> `.gnupg---' ----------------- [ 01:27:37, olli@skylab, ~ ] $ mkdir ~olli/.gnupg; grep -v s2k- /home/olli/.gnupg---/gpg.conf > ~olli/.gnupg/gpg.conf ----------------- [ 01:29:26, olli@skylab, ~ ] $ ----------------- [ 01:34:28, olli@skylab, ~ ] $ grep S2 ~/.gnupg/gpg.conf cipher-algo AES256 ----------------- [ 01:34:44, olli@skylab, ~ ] $ ----cut----- Still having "gpg: invalid item `S2' in preference string" Though: ----cut----- ----------------- [ 01:35:03, olli@skylab, ~ ] $ gpg --version | grep `grep S2 ~/.gnupg/gpg.conf | awk -- '{print $2}'` Cipher: CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), ----------------- [ 01:36:50, olli@skylab, ~ ] $ ----cut----- Thus 'S2' is not a typo here. Also "gzcat /usr/share/man/man1/gpg.1.gz|nroff -man | col -b | grep `grep S2 ~olli/.gnupg/gpg.conf | awk -- '{print $1}'`" gives "--cipher-algo name" along w/ other results and thus an option is also not a typo. Or I miss somth. ? BTW: There're also another gpg issues noted in bug ID "153883". --quote-- And finally: how can I get know how my keyring is encrypted after creating it? --quote-- That question is also important - how a user can check that options given on command line gave exactly what he/she asked for? Well, for father questions around my gpg conf: look the attachment. The gpg.conf is inside tgz. I've attached tgz right after creation of the bugreport w/ corresponding description. bugzilla#153535 is not related to this topic First of all: you mix things. gpg is independent to gpg2 (developer version) to gpgme (gnupg library). Things added to gpg might not be included in the other packages. This is related to the fact that I'm not the maintainer of the gpg2 package nor of the gpgme package. Therefore please open new bugreports to those packages, if you wish to change anything there. This helps us lot in the maintenance of wishes and bugs and reduces the level of confusion here (who has to still do what). Thanks in advance. okay, but please point exactly what should be reported as a separate bug (and for what package) & I'll do that definitely. I'm not sure what & where. According to comment#3, I got the feeling, that you wish the gpg-1.4.0-make-suid-secure.patch of gpg to be added to gpg2, and gpgme. If you wish so, please create those bug reports. if that's a patch around secure-memory, that obsolettes 'require-sec-mem' w/ SuSE - no, I don't. The only thing I'm interested in here is getting documentation (man page & readme) in sync w/ life: /usr/share/doc/packages/gpg/README.SuSE should contain somthing like: 'option require-sec-mem is obsolette w/ SuSE`. That's due to comment #2. Should I open separate bugreport for manual page improvements? I've sent some to people from the list & to a mailing list, but the list itself bouncing my mails back due to strict reverse dns checks. No, I think it's different. The option isn't obsolete, you still need to say via option 'require-secmem' to get some, otherwise you won't. Only the warning doesn't make sense, but only under some certain circumstances and certainly not always. So, if you set 'require-secmem' in your options file, you can set 'no-secmem-warning' either. :-) So I don't think it's really necessary to work on something here. No, please no bugzilla regarding manual page improvement. We are too close to the original code, and our change is documented. As I'm very busy with other (higher prior) tasks, I'll come back and work on the still open points (which are already closed on the mailing list), as soon as time permits. I want to document why the others topics aren't an issue. Coming back to this issue. The 'S2' issue is not a valid issue either. ==> Closing with INVALID Reason: it's necessary that 3DES is enabled for the given options. But as it is not, a key with nonsense options can only be generated. So you get the given S2 warning. The "--expert" option allows you still to generate any such key, even it's not a good idea to so; but as a result you see the warning. The warning is valid, the bug isn't. For the sake of completness: The memory related problem is already discussed before. The bug report is also invalid here. |
The gpg itself is installed suid root. That is noted in BUGS section of the manual: ==============cut===================== BUGS On many systems this program should be installed as setuid(root). This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing memory pages (which may contain passphrases or other sensitive material) to disk. If you get no warn- ing message about insecure memory your operating system supports lock- ing without being root. The program drops root privileges as soon as locked memory is allocated. ==============cut===================== Though it doesn't get its memory secure anyway: ==============cut===================== ----------------- [ 23:46:57, olli@skylab, ~/.gnupg ] $ gpg --verbose --gen-key gpg: will not run with insecure memory due to --require-secmem ----------------- [ 23:46:59, olli@skylab, ~/.gnupg ] $ ==============cut===================== Also there're options in the gpg.conf that'ren't noted as incorrect, but produce warning like this (s2k prefixed options): ==============cut===================== gpg: invalid item `S2' in preference string ==============cut===================== The same thing I get w/ the following options: 1. ==============cut===================== ----------------- [ 23:50:34, olli@skylab, ~/.gnupg ] $ grep s2k gpg.conf | grep -v ^\# s2k-mode 3 ----------------- [ 23:50:54, olli@skylab, ~/.gnupg ] $ ==============cut===================== 2. ==============cut===================== ----------------- [ 23:55:28, olli@skylab, ~/.gnupg ] $ grep s2k gpg.conf | grep -v ^\# s2k-cipher-algo AES256 ----------------- [ 23:55:34, olli@skylab, ~/.gnupg ] $ ==============cut===================== 3. ==============cut===================== ----------------- [ 23:57:42, olli@skylab, ~/.gnupg ] $ grep s2k gpg.conf | grep -v ^\# s2k-digest-algo SHA512 ----------------- [ 23:57:46, olli@skylab, ~/.gnupg ] $ ==============cut===================== 1.,2.,3. above are tested separately w/ the following scenario: ==============cut===================== ----------------- [ 00:05:13, olli@skylab, ~/.gnupg ] $ rm pubring.gpg random_seed secring.gpg trustdb.gpg removed `pubring.gpg' rm: cannot remove `random_seed': No such file or directory removed `secring.gpg' rm: cannot remove `trustdb.gpg': No such file or directory ----------------- [ 00:05:19, olli@skylab, ~/.gnupg ] $ gpg --gen-key gpg: keyring `/home/olli/.gnupg/secring.gpg' created gpg: keyring `/home/olli/.gnupg/pubring.gpg' created Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 5y Key expires at Птн 25 Фев 2011 00:05:41 MSK Is this correct? (y/N) y ==============cut===================== Also the following doesn't work since DSA keys require RIPEMD160 hashing (the key generation stops w/ error about incorrect digest for the DSA key, telling that DSA require RIPEMD160): ==============cut===================== ##### The below does NOT work. DSA has limited hashing. # select hashing for signing keys # cert-digest-algo SHA512 ==============cut===================== That's funny that there're no other key variants that allow encryption (there're variants for signing only). What for that option is needed then? :? If this option is OK only for some types of keys or some specific situations - that should be definitely noted in the man. And finally: how can I get know how my keyring is encrypted after creating it? After "invalid item `S2' in preference string" note from the gpg I wish to know what do I've after running gpg --gen-key in result. How does it treat these 'invalid' options? Choosed another cipher/digest? What utilities should I use to find out? At least the cyphers/digests really used (including lengths of keys really generated) are a question after an error occures. Even having all that ontop of encrypted loop I'm curiouse about that. %)