bugGNU Wget - Bugs: bug #41331, spurious errors if some files in...

 
 

bug #41331: spurious errors if some files in the cert directory are not certificates

Submitted by:  Noël Köthe <nok>
Submitted on:  Fri Jan 24 10:43:10 2014  
 
Category: Program LogicSeverity: 3 - Normal
Priority: 6Status: Fixed
Privacy: PublicAssigned to: None
Originator Name: Open/Closed: Closed
Release: trunkOperating System: GNU/Linux
Reproducibility: Every TimeFixed Release: None
Planned Release: 1.16.1Regression: Yes
Work Required: NonePatch Included: No

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon Dec 1 16:11:21 2014, comment #8:

To not create regressions, only 'c' has been done.
IMHO, 'f' is not a good idea.

Fixed with commit f518d6cea167cac0f66d6e5fbc5cdb30096db50e

Tim Ruehsen <rockdaboot>
Project Administrator
Sun Jun 8 14:40:59 2014, comment #7:

I would go with c and f.

A warning should be printed during --debug output if Wget encounters an invalid certificate file. Also, Wget should only load files with a valid certificate extension, .cert / .pem.

Darshit Shah <darnir>
Project Administrator
Fri Feb 28 12:14:52 2014, 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.

Vincent Lefèvre <vinc17>
Fri Feb 28 11:31:33 2014, 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 !?

Tim Ruehsen <rockdaboot>
Project Administrator
Fri Feb 28 02:29:39 2014, 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).

Vincent Lefèvre <vinc17>
Thu Feb 27 21:44:03 2014, comment #3:

At least, we should change the string 'ERROR' into 'WARNING'.

I personally would like to see if there is something unexpected or broken in my certificate directory. So removing the check resp. the warning completely is not an option to me.

What do you think ?

Tim Ruehsen <rockdaboot>
Project Administrator
Fri Feb 21 11:33:51 2014, 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).

Vincent Lefèvre <vinc17>
Fri Feb 21 10:12:29 2014, comment #1:

I'm unable to reproduce this bug on the current git HEAD and on the v1.15 tag.

I set up my wgetrc file to have a ca_directory which has one cert file and a bunch of other random text files. Trying to download an https page gave me no spurious error messages at all.

Darshit Shah <darnir>
Project Administrator
Fri Jan 24 10:43:10 2014, 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

Noël Köthe <nok>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rockdaboot (Posted a comment)
  • -unavailable- added by vinc17 (Posted a comment)
  • -unavailable- added by darnir (Posted a comment)
  • -unavailable- added by nok (Submitted the item)
  • -unavailable- added by nok
  • -unavailable- added by nok
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Dec 1 16:11:21 2014rockdabootStatusNeeds Discussion=>Fixed
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>1.16.1
    Tue Nov 18 07:38:13 2014darnirCategoryUser Interface=>Program Logic
      Priority5 - Normal=>6
    Sun Jun 8 14:40:59 2014darnirStatusNone=>Needs Discussion
    Fri Jan 24 10:43:10 2014nokCarbon-Copy-=>Added -unavailable-
      Carbon-Copy-=>Added vincent lefevre

    Back to the top


    Powered by Savane 3.1-cleanup