1.1.0h -> lost quotes in c_rehash

[sebastianas]

Since #5533 the c_rehash here has no quotes which were specified in "quotify1":

my $dir = {- quotify1($config{openssldir}) -};
my $prefix = {- quotify1($config{prefix}) -};

See Debian bug 894282. I reverted commit
77ba00b ("util/dofile.pl: only quote stuff that actually needs quoting")

to around it. Any idea?

Sebastian

[jrtc27]

Yeah, it's horribly broken. The backslash-escaping only escapes things which need escaping inside double quotes, and assumes that anything which doesn't need any backslashes also doesn't need quote, but that's not true. Forward slashes don't need to be escaped, but either mean a search pattern or division, based on whether they are at the start of the string. I don't know the full perl grammar, but it seems to me that, if you want to avoid double quotes when not necessary (which seems like a waste of time that causes needless problems like this, if you ask me, but that's not my call), that should be whitelisted with something like [A-Za-z0-9_]+ or whatever the grammar specifies.

[levitte]

Side note: the given URL for the Debian bug report didn't work for me, but this does: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894282

[levitte]

Thank you for the report, btw. Will fix.

[jrtc27]

Yeah, it's either bugs.d.o/BUGNUM or bugs.d.o/cgi-bin/bugreport.cgi?bug=BUGNUM, not bugs.d.o/cgi-bin/BUGNUM.

[levitte]

I did, however, make that change for a reason... Unfortunately, I can only remember vaguely something about an empty argument that shouldn't have been there because some perl array contained an undef or something like that.

Anyway, I'm reverting that change and seeing what breaks because of it. Be right back...

[levitte]

Side note: while I understand the nature of habit, I would urge those who can (and this most definitely includes Linux as far as I know) to switch to use openssl rehash. c_rehash is a kinda fallback script that will disappear at some point.

[CyrilBrulebois]

Regarding the side note: I'm seeing fewer symlinks generated by openssl rehash compared to c_rehash… Is there any documentation regarding your recommendation to switch and the possible side effects?

[kroeckx]

On Wed, Mar 28, 2018 at 08:15:06AM -0700, Cyril Brulebois wrote: Regarding the side note: I'm seeing fewer symlinks generated by `openssl rehash` compared to `c_rehash`… Is there any documentation regarding your recommendation to switch and the possible side effects?

The c_rehash in Debian is patches to provide both the new and old symlinks, because when we switched to the new other libraries like gnutls broke. I have no idea what the current state is.

[sebastianas]

On 2018-03-28 16:46:11 [+0000], Kurt Roeckx wrote: On Wed, Mar 28, 2018 at 08:15:06AM -0700, Cyril Brulebois wrote: > Regarding the side note: I'm seeing fewer symlinks generated by `openssl rehash` compared to `c_rehash`… Is there any documentation regarding your recommendation to switch and the possible side effects? The c_rehash in Debian is patches to provide both the new and old symlinks, because when we switched to the new other libraries like gnutls broke. I have no idea what the current state is.

The -compat/md5 option in Debian was forced in due to #622679 in 2011. gnutls-cli uses /etc/ssl/certs/ca-certificates.crt and does not care if the symlinks are gone. It won't do anything if the symlinks are available (md5+sha1) but the ca-cer…crt file is missing. This is now. It seems that we can drop that compat from GnuTLS point of view. I will open a bug against ca-cert and asking them to replace `c_rehash' with `openssl rehash' instead and ping the gnutls deb maintainer if they know anything about the need regarding the md5 hash. Sebastian