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

Submitter:  Noël Köthe <nok>
Submitted:  Fri 24 Jan 2014 10:43:10 AM UTC
   
 
Category:  Program Logic Severity:  3 - Normal
Priority:  6 Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  trunk Operating System:  GNU/Linux
Reproducibility:  Every Time Fixed Release:  None
Planned Release:  1.16.1 Regression:  Yes
Work Required:  None Patch Included:  No
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 01 Dec 2014 04:11:21 PM UTC, 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>
Group administrator
Sun 08 Jun 2014 02:40:59 PM UTC, 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>
Group administrator
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.

Vincent Lefèvre <vinc17>
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 !?

Tim Ruehsen <rockdaboot>
Group administrator
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).

Vincent Lefèvre <vinc17>
Thu 27 Feb 2014 09:44:03 PM UTC, 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>
Group administrator
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).

Vincent Lefèvre <vinc17>
Fri 21 Feb 2014 10:12:29 AM UTC, 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>
Group administrator
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

Noël Köthe <nok>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-12-01 rockdaboot StatusNeeds Discussion Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.16.1
    2014-11-18 darnir CategoryUser Interface Program Logic
        Priority5 - Normal 6
    2014-06-08 darnir StatusNone Needs Discussion
    2014-01-24 nok Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added vincent lefevre <vincent@vinc17.net>

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code