Fri 28 Feb 2014 12:14:52 PM UTC, comment #6:
I would say c. Perhaps f could be OK too and could be even safer, but this is partly unrelated to the error/warning message.
e may not be sufficient. For instance, a user may want to rename some buggy/old certificate by adding the ~ character at the end of the file name (or ".bak", or ".old") in order to ignore it. And that's why I think that f is safer than the current behavior. This is similar to new requirements by some new software versions (e.g. recent Apache) such as: configuration files in ".d" directories must have a ".conf" extension.
|
Fri 28 Feb 2014 11:31:33 AM UTC, comment #5:
Before I create a patch, I would like to know what you suggest. At least such a suggestion should satisfy the widest possible range of users.
Some options could be (single or combination)
a. Output WARNING instead of ERROR
b. Output ERROR only with --debug enabled
c. Output WARNING only with --debug enabled
d. Suppress any output
e. Ignore executables (i guess your scripts have the X flag set)
f. Just read .pem and .crt files
I personally tend to c.
To get rid of the messages, you could also create a subdirectory for your scripts.
(I also would like to change the code to ignore .* files, but that might be another patch.)
Maybe some more people could post their opinions !?
|
Fri 28 Feb 2014 02:29:39 AM UTC, comment #4:
Having a file that is not a certificate is not something broken. The message is distracting and can make more useful messages less visible.
Also, wget is not the right tool to see if something is broken in the certificate directory. Even if something is broken, when I run wget, I don't want to be distracted by any error that doesn't affect the current download.
I have a script (which is run by cron every night, but can also be run manually, e.g. after updating the certificates) that does a
openssl verify -CApath . *.{crt,pem}
so that I can see whether something is wrong, such as an expired certificate. BTW, that's this script (and another one) that makes wget complain. I've put it in the directory so that everything related is at the same place (and if I move or rename the directory, I don't have to update the script).
|
Fri 21 Feb 2014 11:33:51 AM UTC, comment #2:
In my case, a strace shows, e.g. for an empty file "empty":
10268 stat("/home/vinc17/wd/config/cacert/empty", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10268 open("/home/vinc17/wd/config/cacert/empty", O_RDONLY) = 6
10268 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10268 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
10268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f28e046b000
10268 lseek(6, 0, SEEK_CUR) = 0
10268 read(6, "", 8192) = 0
10268 close(6) = 0
10268 munmap(0x7f28e046b000, 4096) = 0
10268 write(2, "ERROR: Failed to open cert /home"..., 69) = 69
In Debian, wget is built with:
+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/gnutls
Darshit, is wget built with gnutls or openssl in your case?
The problem comes from:
if ((rc = gnutls_certificate_set_x509_trust_file (credentials, ca_file,
GNUTLS_X509_FMT_PEM)) <= 0)
logprintf (LOG_NOTQUIET, _("ERROR: Failed to open cert %s: (%d).\n"),
ca_file, rc);
else
ncerts += rc;
while in wget 1.13, the return value of gnutls_certificate_set_x509_trust_file was not checked. This error message serves no purpose since the "failure" doesn't prevent the URL from being opened (using the right certificates).
|
Fri 24 Jan 2014 10:43:10 AM UTC, original submission:
Hello,
a forwarded Debian bug (wget version 1.15; the release option in the savannah bug tracker only lists until 1.13.4):
--8<--
In my .wgetrc file, I use:
ca_directory = ~/wd/config/cacert
With wget 1.15, I get the following errors when downloading a https URL:
ERROR: Failed to open cert /home/vlefevre/wd/config/cacert/c_rehash: (-207).
ERROR: Failed to open cert /home/vlefevre/wd/config/cacert/vfy: (0).
The reason is that c_rehash and vfy are not certificates. wget is the
only program to complain, and it didn't before version 1.15.
--8<--
https://bugs.debian.org/736427
Regards
Noël
|