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 24 Jan 2014 10:43:10 AM UTC  
 
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 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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 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 01 Dec 2014 04:11:21 PM UTCrockdabootStatusNeeds Discussion=>Fixed
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>1.16.1
    Tue 18 Nov 2014 07:38:13 AM UTCdarnirCategoryUser Interface=>Program Logic
      Priority5 - Normal=>6
    Sun 08 Jun 2014 02:40:59 PM UTCdarnirStatusNone=>Needs Discussion
    Fri 24 Jan 2014 10:43:10 AM UTCnokCarbon-Copy-=>Added -unavailable-
      Carbon-Copy-=>Added vincent lefevre

    Back to the top


    Powered by Savane 3.1-cleanup