What is the threat model for this? If you are able to ptrace a process you can
do all other kind of stuff, like replacing gpg with your own code. If the box
has been taken over, we are in game-over state.
Disabling core dumps is a different issue because a core dump leaves traces of
the process on the disk.
The option --default-cert-level is described in the manual.
Thus, this bug report is about web.
Changing "category" from gnupg to gpgweb.
I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.
I just backported the new ssh-agent code from master to the 2.0 branch. Thus
2.0.21 will have this support.
Hello Werner,
GnuPG uses setrlimit do disable core dumps. It has always done so. See
common/sysutils.c:disable_core_dumps. Do you have a test case which shows that
it does not work?
Please recall that gpg is a Unix command line tool and as such it need to stcik
to common conventions. Only messages which are deemed to be necessary are
printed. Chnages to the key generation dialog would be veryhard because gpg is
used by several other programs as a backend and they assume a certain order of
prompts.
I suggest that you use one of the graphical frontends for key generation.
Thanks for your answer, I'll do that then.
Loïc Gomez
If you want to rely on the exit coide, you can't use gpg. There are simply too
many things to consider and everyone has a different policy. I commonly use AWK
scripts to implement such policies by parsing the --status-fd output.
The tool you might want to use is gpgv which has been designed for these
purposes. In fact, it is used by all Linux distros to verify the integrity of
the downloaded packages against a specific keyring. Please check out the gpgv
man page.
We need to see whether we can re-use the code from GPA for this purpose.
Fixed in 0.9.4, coming soon.
Pending for a long time; should be considered for 2.1
Done for 2.0
Tested patches are welcome (against git master of course).
Fixed in master
Is that still something we should go for?
We plan to do something similar for the Informsec grant.
Marking as resolved, as this seems to work fine now as far as I can tell (I'm
certainly happy).
scrypt has now been implemented.
Done in master.
If you use --textmode during encryption the native line endings on the
decryption system are used. Adding an extra option to for arbitrary conversions
is IMHO not a good idea beause it violates the Unix principle of having
dedicated tools which work together. tr(1) does what you want.
1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.
Still have this issue. Here is an updated patch against 2.0.19. Please
consider including it, or provide some feedback if this is a bad idea / should
be done a different way.
Marking this as a bug since it restores useful functionality that was lost.
No. See the discussion on the maling lists for the reason why we limit the RSA
key size to 4k.
Again a warning: Do not propose the use of such large keys. The end effect is
that people don't use encryption because it is too slow on non-big machines.
See the Topics field above: wontfix.
The feature request has been rejected. If you still want to pursuit it, please
start a discussion at gnupg-devel and don't contine here at the BTS.
Not ure to understand you comment...
Have you added support for XDG basedir spec?
Add more complexity to the already complex configuration.
Please notice that backward compatibility can be preserved by continue to use
$HOME/.gnupg if it exits but using/creating XDG dirs when it is not exit.
That would be incompatible to previous versions and is thus not an option. If a
user wants this GNUPGHOME provides an easy way to do so. Keys should be
considered part of the configuration.
We won't do this for 1.4.
I would say this should go into 2.1.
What is your threat model?
It is already available in the latest 2.1-beta.
That is not possible for two reasons:
Ok I did some more research on this topic and it appears ECC is the fix for RSA
additional key sizes. Do you have any idea when ECC will be implemented into
this gem? This draft appears to be expired though so its unknown to me if there
are plans to get this implemented into the default software without requiring a
patch.
Draft: https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11
Once again thanks for the feedback. I tried to search but I kept getting errors
so I apologize if this was previously addressed.