how do other clients do it?

maybe a better default would suffice.  alternatively a popdown box on the
security page?
 

other clients presumably fork and run the gpg binary as a subprocess.

the gpg binary readis its configuration file, and notices i want a different
hash by default; presumably, Evo uses the library back-end to gpg instead of
running the binary, and (also presumably) the library routines don't go reading
$HOME/.gnupg/gpg.conf by themselves. i do not know if they can be told to do so
or not.

for *my* needs, a better default would most certainly suffice -- may i recommend
SHA-256 for now? if that's not acceptable to everybody, then a drop-down box
would be good too. but since this is not a setting one is likely to use often,
hiding it someplace inconspicuous might actually be a good idea; i imagine it
would only ever be needed when communicating with somebody whose PGP client is
broken or outdated.

we also just fork gpg.

then i have no idea why the forked-off gpg doesn't read and obey its config
file? gpg run from my command line behaves as i expect it to.

perhaps Evo resets some environment variable gpg needs? although according to
its man page, even if $GNUPGHOME isn't defined, it should still default to
~/.gnupg (which is what i'm using). maybe resetting $HOME might confuse it; does
Evo do that, perhaps?

no

*** Bug 314037 has been marked as a duplicate of this bug. ***

the problem is that we must explicitly specify the hash algorithm because we
need to create additional headers which are part of the pgp/mime specification.

i'd still like to know how other clients do it.

an example message would do.  e.g. set the gpg hash to some non-rfc version, and
see what the mail header says.  then try it with sha1 and see what it says there.

Created attachment 51256 [details]
email message signed w/ SHA-256, created w/ mutt

Created attachment 51257 [details]
email signed w/ SHA-1, created w/ mutt

Comment on attachment 51257 [details]
email signed w/ SHA-1, created w/ mutt

(*argh*. patch #51257 is worng, should be deleted; user error, my mistake.)

Created attachment 51258 [details]
email signed w/ SHA-1, created w/ mutt

this time i will surely upload the right file(tm).

by way of explanation ---

i don't have easy access to very many other mail clients, since Evo has
converted me pretty thoroughly. but i still have mutt around, and it does crypto
hashing the way attachments #51256 and #51258 illustrate. these emails show up
as having valid signatures in Evo, and clicking the signature icon will show the
relevant hash algorighms properly.

sorry about the screwed-up attachment in the middle there. no caffeine yet this
morning.

the gpg code I wrote allows one to pass a hash algorithm to use but the list
doesn't contain sha-256 afaik because when I wrote the code, it wasn't available
in gpg as a command-line specified hash algo. is it now? and if so, which version?

(note: I had to read gpg code to get a list of algos which was not pleasant
because the docs were insufficient)

anyways... we could probably introduce a UI to select the hash algo... the
backend code can already handle it (other than sha-256 which would be trivial to
add once we know the name to pass to gpg)

$ gpg --version
gpg (GnuPG) 1.4.1
Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512
Compression: Uncompressed, ZIP, ZLIB, BZIP2

i don't know how long SHA-256 has been available, but at least since GnuPG
v1.2.4; Mandrake 10.1 ships with that version as standard, and it already has
the first four hash algos my home-compiled v1.4.1 brags about above. according
to my man page (and the v1.2.4 man page in stock Mandrake), the command-line
switch should be "--digest-algo _name_", with the options for _name_ listed in
the output of "--version".

"(note: I had to read gpg code to get a list of algos which was not pleasant
because the docs were insufficient)"

You did?  They're all listed in the rfc are they not?

5.  OpenPGP signed data
[...]
   Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
   "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".

Which is part of the problem.  Only THOSE micalg's have been defined by iana, so
any newer ones aren't actually standardised - regardless of whether gnupg may or
may not support them (at least, as far as i've been able to determine).

We could perhaps change the composer code to pass HASH_DEFAULT, and then the
camel-gpg-context could check the gpgrc file for the hash to use, or fallback to
sha1, which is guaranteed to be available.

Otherwise we're going to have to add all the new possible hash types, and have a
ui to select which one to use; a much bigger problem.

btw how did you specify to mutt which hash to use, did you specify it explictly,
or just change the gpg options?

blah, I dunno, maybe I misremembered. or maybe it was for the names to pass to
gpg on the command-line. I forget.

i didn't tell mutt which hash to use, i just fiddled with $HOME/.gnupg/gpg.conf
to switch from one to the other. for the record, this was mutt v1.5.6i, compiled
with +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME 

Created attachment 51364 [details] [review]
composer uses default hash

Created attachment 51365 [details] [review]
implement gpg options parsing to find default hash

These patches implement looking into the gpg options file for the digest hash
algorithm.

I'm not entirely sure about them though; e.g. using sha256 doesn't work with all
keys. e.g. the default key type from gpg --gen-key.  And if it fails you get a
pretty cryptic error message.

Maybe given that you have to explicitly override it, it might not be a problem
for most users.

*** Bug 320876 has been marked as a duplicate of this bug. ***

Hi Jeffrey

Why are the patches in #320876 wrong?

+	case CAMEL_CIPHER_HASH_DEFAULT:
+		return "pgp-default";

wrong, no such hash algo pgp-default

+		else if (!strcmp (id, "pgp-default"))
+			return CAMEL_CIPHER_HASH_DEFAULT;

wrong, no such hash algo pgp-default

-			camel_cipher_sign(cipher, pgp_userid, CAMEL_CIPHER_HASH_SHA1, part, npart, &ex);
+			camel_cipher_sign(cipher, pgp_userid, CAMEL_CIPHER_HASH_DEFAULT, part,
npart, &ex);

wrong because the migcalg parameter of the Content-Type header for the
multipart/signed MIME part will be incorrect.

still valid in 2.7.3, any mailer hacker taking a look at this? partha, varadhan?

Is there any hope of this being fixed before the next stable release is out? I would really appreciate a fix.. I even tried writing a patch for it (above), but it seems to be incorrect due to my understanding of Evolution, but I want this issue fixed nevertheless as a user of Evolution. Even a gconf-igurable method of configuring the hash is acceptable as long as it can be configured.

mukund: if you compile on your own, try out not zed's two patches attached here.

we should try to target this issue for 2.10 - sha-1 is becoming less secure,
http://www.heise-security.co.uk/news/77244 . we already have a patch here which could be reworked.

The Heise article is certainly alarming. If nothing, atleast the default hash algorithm should be changed to something else first-hand.

it can't be changed because not all keys can use any hash algorithm. That is why Evolution passes "use default hash algo" to gpg, and gpg defaults to sha-1 for most keys (might default to md5 for others, god knows).

Good point.

Btw, keys will need to be revoked anyway if SHA-1 is weak, as if it's possible to get to the same hash using two datasets, the key is effectively compromised for signatures.

Bumping version to a stable release.

For the record, evolution 2.26.1 uses the following command line:

corsac   16543  0.0  0.0 106956  1840 ?        SLs  08:08   0:00 gpg --verbose --no-secmem-warning --no-greeting --no-tty --status-fd=61 --command-fd=62 --sign --detach --armor --digest-algo=SHA1 -u C5C05BAE --output -

So it forces the --digest-algo instead of using the gpg.conf instructions. Just removing that should enable users to chose what they want without fiddling with evolution.

Cheers,

*** Bug 589637 has been marked as a duplicate of this bug. ***

SHA-1 is getting more and more broken the longer this goes.  The best known chosen pre-image attack dropped significantly in complexity (to the point of being accessible to a small corporation) quite recently.

Moving /usr/bin/gpg to /usr/bin/gpg.real and replacing putting this script in /usr/bin/gpg is an ugly hack around the problem:

#!/bin/bash

if ls -l /proc/$PPID/exe | fgrep -e /usr/bin/evolution >/dev/null; then
    declare -a newopt
    for opt in "$@"; do
        if [ "$opt" != "--digest-algo=SHA1" ]; then
            newopt[${#newopt[@]}]="$opt"
        fi
    done
    exec /usr/bin/gpg.real "${newopt[@]}"
else
    exec /usr/bin/gpg.real "$@"
fi

Created attachment 140029 [details] [review]
Patch for evolution 2.26

I use two patches for evolution and evolution-data-server which simply remove the default hash algorithm, thus leaving it to gnupg. gnupg's default is SHA1.

These patches apply to evo2.26 and eds2.26 resp. I have not tested them with 2.27 yet, though.

IMHO, evolution should leave those details to the application which is specialised in.

Created attachment 140030 [details] [review]
Patch for evolution-data-server 2.26

The approach in these patches, while simple, seems to conflict with comment #7.

I need to read up further to better understand what headers Not Zed was referring to.  Any help or advise here would be appreciated.

Indeed. The patched e-d-s now fails to create the "micalg=" part of the Content-Type header. But that part is required by other clients like Thunderbird and Seamonkey. Maybe it is possible to parse the verbose output of gnupg (STDERR), which is similar to "gpg: DSA/SHA512 ...".

Regarding comment #16: according to section dropped out of the RFC3156 quote, micalg values may be generated for new hash algorithms according to the specification in RFC2440:

   The "micalg" parameter for the "application/pgp-signature" protocol
   MUST contain exactly one hash-symbol of the format "pgp-<hash-
   identifier>", where <hash-identifier> identifies the Message
   Integrity Check (MIC) algorithm used to generate the signature.
   Hash-symbols are constructed from the text names registered in [1] or
   according to the mechanism defined in that document by converting the
   text name to lower case and prefixing it with the four characters
   "pgp-".

That being said, IANA does define SHA-2 algorithms ( http://www.iana.org/assignments/hash-function-text-names/ apparently as of 2006-08-18), so it should be possible to set standard micalg values for sha-512

Thank you very much for your hints to the problem.

Those patches which I published here are stupid, to be honest, since they break the interoperability to other mail clients. Interoperability means if you provide a Content-Type: header with "application/pgp-signature" as protocol, you should notify the hash algorithm (micalg=) as well. That is what comment #7 says and what is broken by my patches.

Seamonkey and Thunderbird do not even try to manage this header field, providing signing inline (by enigmail). Thus they do not need to *know* about the exact hash algo used, they use your settings:


Content-Type: text/plain; charset=UTF-8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

sm
äöüß
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEAREKAAYFAkp8w3AACgkQkMWCXeoD6HT0YQCePOiKRVDqA7y2uWU5Oj9TfYPM
NXkAn1msaVwAW7o/Q+ZY7BkGVZRR3ENW
=eiu5
-----END PGP SIGNATURE-----

and so on.

Maybe it would be worth to re-use that pattern.

Or you could parse the stderr_fd to obtain the hash algo, and you are hostile to changes in gnupg's err_output and localisation.

Why do not we go the easy way?

Enigmail by default does not use OpenPGP/MIME - it embeds OpenPGP blocks into the text of the message. This is not the standard way of doing stuff and can't be used unless you handle all your communications in plain text messages without any attachments.

When Enigmail is set to use OpenPGP/MIME, it suffers from the same problem Evolution has - it must know the hash algorithm used and thus it must set it, and thus it must use SHA-1. (BTW - I haven't managed to convince Enigmail to use another hash algorithms for inline OpenPGP - even though my preferences are set correctly).

I think the best course of action is to develop a library backend for gpg that allows one to have a serious and intelligent discussion with gpg about available and preferred algorithms, before doing the actual signing. I'll see if I can come up with something, but I have little time and ATM absolutely no knowledge of GPG's internals (so don't expect anything soon) 

Maybe you could use gpgme: http://www.gnupg.org/related_software/gpgme/

It seems to provide all necessary.

(In reply to comment #44)
> When Enigmail is set to use OpenPGP/MIME, it suffers from the same problem
> Evolution has - it must know the hash algorithm used and thus it must set it,
> and thus it must use SHA-1.

This hasn't been true for a while now: Enigmail has a function determineHashAlgorithm that signs a test message to figure out what hash GPG will use for the real message.

So that's another option.

And what about still forcing the hash algo (until the correct solution is found) but enable users to choose it, and above all, not use SHA-1 by default (use SHA-256 for example)

(ping ?)

Created attachment 152778 [details] [review]
add sha-2 hash IDs to evolution-data-server

These patches don't fix the bug yet, but they're definitely a prerequisite.

Created attachment 152779 [details] [review]
add sha-2 hash IDs to evolution-data-server

These patches don't fix the bug yet, but they're definitely a prerequisite.

Created attachment 152780 [details] [review]
add sha-2 algos in OpenPGP

(double post, bugzilla timed out on me)

Created attachment 152781 [details] [review]
add sha-2 algos in S/MIME

Created attachment 152785 [details] [review]
first patch: add sha-2 hashes to evolution-data-server

(This version updates the documentation, too)

This bug is not fixed since 2005?

It seems so. I am experiencing the exact same problem right now with Evolution 2.28.3.1. It would be really really great if someone would fix this. Currently I am using the workaround from Eric (Thanks for it ;-))

(In reply to comment #55)
> It seems so. I am experiencing the exact same problem right now with Evolution
> 2.28.3.1. It would be really really great if someone would fix this. Currently
> I am using the workaround from Eric (Thanks for it ;-))

You're welcome.  It's really ugly though.  :-)

I'm amused that the GNOME team prioritizes removing the option for focus-follows-mouse over fixing this vexing security issue.

At least it doesn't seem to be being ignored.

Bug still exists in 2.30.0.1

Created attachment 158960 [details] [review]
Adds some SHA-algos

I attached a quick & dirty implementation of nobled's suggestion (comment #46).

The default digest algo of gpg is determined by the following pipe of shell-commands:

echo|gpg --clearsign 2> /dev/null|head -n 2|tail -n 1|sed -e 's/Hash: //'

The first two patches adds the needed SHA-algos to evoluton-data-server, the last one replaces the hardcoded CAMEL_CIPHER_SHA1 by a call to the new funtion gpg_get_default_digest() which does the dirty work-around in plain C w/o the e-d-s API.

Created attachment 158961 [details] [review]
Adds some SHA-algos part 2

Created attachment 158962 [details] [review]
Patch for evolution 2.30 to determine gpg's default digest

Created attachment 159044 [details] [review]
Patches evolution-data-server 2.30 to support SHA2-class of digests

Actually I implemented the same as above, but this time using the e-d-s framework.

e-d-s then offers a function called gpg_ctx_get_default_digest which allows evolution (patch will follow) to automatically determine the digest algorithm of gpg by constructing a gpg_ctx:
gpg --clearsign -u <userid> --detach ...
whenever gpg_sign'ing is requested (hence an overhead for a bit more flexibility). The output contains the name of the used algo which is then transformed to the corresponding CAMEL_CIPHER_HASH_*.

The API of e-d-s changed in that gpg_sign(), hence the normally used camel_cipher_sign() function will take an additional, but optional argument of the type _GpgCtxMode¹ that is only relevant if it is GPG_CTX_MODE_SIGN or  GPG_CTX_MODE_CLEARSIGN (with the latter also added by the attached patch).

I expect the attached code to be buggy, so handle it with care.

-- 
¹ BTW, with the patch applied this enum is no longer private to the gpg context because it is needed in the camel_cipher_ctx as well.

Created attachment 159045 [details] [review]
Replace the hardcoded CAMEL_CIPHER_HASH_SHA1 with a call tpo gpg_ctx_get_default_digest

Really ugly bug.
2.28.3.1. and 2.30.0.1 affection confirmed (Ubuntu 9.10, 10.04)

BTW happily using Eric's solution :)
Just for the record - don't forget to set execution bit on Eric's script, for example 
$ sudo chmod 755 /usr/bin/gpg
Yep, I forgot and experienced nice "broken-pipe" error inside evolution.

What really worries me now is 
Priority:  	Normal

5-year old security issue simply isn't normal...

Thanks for the patches Steffen. 
Unfortunatelly I don`t have the time to do some serious testing, at the moment, since I am writing my A-Level Exams in the next weeks. However I will do some testing as soon as they are over.
Just wanted you to know that I really appreciate you effort.

As for descent89's statement, I definitly agree. This bug is known since five years and should really be fixed by now.

Created attachment 159982 [details] [review]
Ads support for SHA2 digests and for automatic determination of GnuPG's default

Thank you very much and good luck in your exams.

I have attached a slightly modified patch for evolution-data-server 2.30.x. BTW, this workaround introduces a drawback by design because it actually signs twice for the same user-id. So if you do not run the friendly gpg-agent in the background you would be required to enter your passphrase twice and evolution will not tell you why. That would clearly look like a bug. But at least it does the trick.

Review of attachment 159982 [details] [review]:

I'm not sure whether it's only a typo or you really wanted to add anything about GPG to camel-cipher-context.h, but if so, the it's plain wrong, it shouldn't ever be there. Thus I'm rejecting this patch. Also, if we cannot support some algorithm in both S/MIME and GPG, then it cannot be added to the list of algorithms in camel-cipher-context.h.

Review of attachment 159045 [details] [review]:

Not the best thing too, the similar thing is used for S/MIME as well, few lines below your change. The correct thing would be to use CAMEL_CIPHER_HASH_DEFAULT and let the GPG or S/MIME chose itself in the background. The best thing would be to have an option for signature algorithm somewhere, maybe per account, but as the first step some general option would be sufficient.

Steffen, please do not take me wrong, the work is appreciated, just the design is not correct, not an evo way. I'll join Nobled's and Steffen's work into some patches to make this done finally.

Hi Milan:

My patches were only meant as a proof of concept, not to be integrated to e-d-s. I just wanted to see how one could implement the idea from comment #46 and what would be the consequences. Well, the patches work as described, look ugly and break the design of e-d-s as expected.

@#66: It is not a typo but IIRC necessary to expose the --clearsign mode of gpg (the _GpgCtxMode enum) to camel_cipher_sign() to avoid a wrapper or something like that. Just for laziness ;-)

Wrt SHA-2, RFC3156 (http://www.faqs.org/rfcs/rfc3156.html) reads:
«5.  OpenPGP signed data

[...]
   The "micalg" parameter for the "application/pgp-signature" protocol
   MUST contain exactly one hash-symbol of the format "pgp-<hash-
   identifier>", where <hash-identifier> identifies the Message
   Integrity Check (MIC) algorithm used to generate the signature.
[...]
   Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
   "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".»

SHA-2 et al. work for PGP-signing but may be unusable or unacceptable for S/MIME, I do not know.

@#67: That is exactly the point. But it is not too trivial to let the choice to gpg (where it belongs IMHO) and to read back what gpg actually has done. One possibility is to sign and analyze a test message what could lead to the drawback described in #65. But with the patch you can change the digest algo at runtime for every single message what is the direct opposite to the current situation ;-)

The other way round would be solid but require the user to put the *right* digest-algo into the gpg option system (for other applications than evolution) and evolution as well. Besides, you should be able to select that algo for every gpg key you want to use (i.e., for every account) because it is not sure whether the preferred method will work for all reasonable key-types and -lengths.

OK, as proof of concept it's fine, good to know it's doable. Thanks.
I'm attaching updated patches, which I'm committing to master.

Created attachment 161493 [details] [review]
eds patch

for evolution-data-server;

- added CAMEL_CIPHER_HASH_SHA256/SHA384/SHA512 enum values
- GPG - CAMEL_CIPHER_HASH_DEFAULT let's GPG choose the signature algorithm,
        and then reads it and uses it in MIME header
- SMIME - reads default signature algorithm from a certificate
- Expanded EAccount for pgp_hash_algorithm/smime_hash_algorithm values

Created attachment 161495 [details] [review]
evo patch

for evolution;

- per-account settings for hash algorithm used for signatures on GPG and S/MIME,
  available options are: Default, SHA1, SHA256, SHA384, SHA512
- composer chooses hash algorithm based on account preferences
- added texts for sha256/384/512 to the certificate view, to know about them
  (it was showing with Object Identifier, instead of pretty description)

Created commit ab727fa in eds master (2.31.2+)
Created commit 98adb40 in evo master (2.31.2+)

Wow, thanks Milan. 
Just compiled the latest eds and evo and it worked like a charm! Tested it with a friend and with an E-Mail to myself. Absolutly no problems (On an 64bit Arch Linux system). This is really really great. Finally this bug is fixed for me!

Thank you for this, you are really doing a great job.

Also many thanks to steffen again, for getting this ball rolling.

Its for people like you I love Linux.

Hello evo developers

Could you please commit these changes also to gnome-2.30 branch and release a 2.30.2 version including all commited patches? (they are a ton that, even working fine, requires some work downstream to provide all of them)

Thanks a lot

These patches cannot go into 2.30 because they break API in both libcamel and libedataserver.

OK, thanks a lot for the info

Still not fixed in 2.30.3.

Going on six years...

It's fixed in 2.32, you know?

My mistake. Figured newest version would've made it into Maverick's repos. Figured wrong.

(In reply to comment #79)
> It's fixed in 2.32, you know?