Mailing List Archive: the default FETCHCOMMAND with broken ssl certificates

the default FETCHCOMMAND with broken ssl certificates

petteri.raty at saunalahti

Aug 7, 2005, 1:46 PM

Post #1 of 7 (535 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One of the java packages, jdictrayapi, is only available over ssl. Here
is the output I get if I try downloading it with wget:

betelgeuse@pena ~/java $ wget
https://jdic.dev.java.net/files/documents/880/16466/jdic-0.9.1-src.zip
- --23:37:11--
https://jdic.dev.java.net/files/documents/880/16466/jdic-0.9.1-src.zip
=> `jdic-0.9.1-src.zip'
Resolving jdic.dev.java.net... 64.125.133.206
Connecting to jdic.dev.java.net|64.125.133.206|:443... connected.
ERROR: Certificate verification error for jdic.dev.java.net: unable to
get local issuer certificate
To connect to jdic.dev.java.net insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

It is usually not a problem for users because the file gets mirrored but
when doing version bumps I come across this again. As a solution I added
- --no-check-certificate to my FETCHCOMMAND so this will not bother me
again.
So what about adding this as the default for everyone? The verification
of the download is done on our side so we don't really need the ssl
certificate checking and it would probably be (very?) little faster
without checking. It could also prevent a couple of bug reports from the
users in the future.

Regards,
Petteri RÃ¤ty (Betelgeuse)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC9nMtcxLzpIGCsLQRAlzZAJ4kdzlqoMqAEUkzTtGIx1yrmTh5AQCeKWGA
Q+KqbGA8Fn5LhZzUCC+8z5E=
=86C3
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

jakub at gentoo

Aug 7, 2005, 1:52 PM

Post #2 of 7 (519 views)

7.8.2005, 22:46:39, Petteri Räty wrote:

> It is usually not a problem for users because the file gets mirrored but
> when doing version bumps I come across this again. As a solution I added
> - --no-check-certificate to my FETCHCOMMAND so this will not bother me
> again.
> So what about adding this as the default for everyone? The verification
> of the download is done on our side so we don't really need the ssl
> certificate checking and it would probably be (very?) little faster
> without checking. It could also prevent a couple of bug reports from the
> users in the future.

Check Bug 101457.

--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

betelgeuse at gentoo

Aug 7, 2005, 2:05 PM

Post #3 of 7 (522 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Moc wrote:
>
>
> Check Bug 101457.
>
>

How unlucky. I actually came across this problem days ago and searched
bugzilla for it. Just didn't get around to writing the email until now.
I will add my thoughts to the bug.

Regards,
Petteri RÃ¤ty (Betelgeuse)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC9neEcxLzpIGCsLQRAmVjAJ9sIf1EXyPpwwcuM2RM2XDhuqNpCQCdFzqv
N4tqpC7By7/SCzoKI6mVY5E=
=y5qy
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

lars at strojny

Aug 8, 2005, 1:26 AM

Post #4 of 7 (518 views)

Hi,

On Sun, Aug 07, 2005 at 11:46:39PM +0300, Petteri RÃ¤ty wrote:
[...]
> It is usually not a problem for users because the file gets mirrored but
> when doing version bumps I come across this again. As a solution I added
> - --no-check-certificate to my FETCHCOMMAND so this will not bother me
> again.
> So what about adding this as the default for everyone? The verification
> of the download is done on our side so we don't really need the ssl
> certificate checking and it would probably be (very?) little faster
> without checking. It could also prevent a couple of bug reports from the
> users in the future.

Would be sensible. Also it would make sense to add --user-agent="Whatever"
to the default configuration, because there are some mirrors of free
software which do not like interacting with a client with an empty user-
agent string.

Greets, Lars
--
name: Lars Strojny web: http://strojny.net
street: Yorckstrasse 22 blog: http://usrportage.de
city: D-71636 Ludwigsburg mail/jabber: lars@strojny.net
f-print: 6663 1055 543E 3106 3FD3 4F40 AC74 CD1F C327 14BD
break your gentoo: http://www.breakmygentoo.net

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

flameeyes at gentoo

Aug 8, 2005, 1:41 AM

Post #5 of 7 (521 views)

On Monday 08 August 2005 10:26, Lars Strojny wrote:
> Would be sensible. Also it would make sense to add --user-agent="Whatever"
> to the default configuration, because there are some mirrors of free
> software which do not like interacting with a client with an empty user-
> agent string.
Well wget already provides an user agent string, something like Wget/1.10.
When a server refuses a connection from this useragent string, it means that
they *don't* want Wget to download from them, so I don't really think it's
the case to change this default string.

--
Diego "Flameeyes" PettenÃ²
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

mcummings at gentoo

Aug 8, 2005, 2:46 AM

Post #6 of 7 (518 views)

On Mon, 8 Aug 2005 10:41:49 +0200
"Diego 'Flameeyes' PettenÃ²" <flameeyes@gentoo.org> wrote:
> Well wget already provides an user agent string, something like
Wget/1.10.
> When a server refuses a connection from this useragent string, it
means that
> they *don't* want Wget to download from them, so I don't really think
it's
> the case to change this default string.
>
That's not always the case though. I know some mirrors would allow
wget's with user defined, even if defined to a generic "Gentoo User
Downloading Agent", but don't allow blank connections at all. I think
the suggestion was whether there could be a way to set this default for
portage.

Re: the default FETCHCOMMAND with broken ssl certificates [ In reply to ]

Aug 8, 2005, 4:33 AM

Post #7 of 7 (538 views)

maillog: 08/08/2005-05:46:30(-0400): Michael Cummings types
> On Mon, 8 Aug 2005 10:41:49 +0200
> "Diego 'Flameeyes' PettenÃ²" <flameeyes@gentoo.org> wrote:
> > Well wget already provides an user agent string, something like
> Wget/1.10.
> > When a server refuses a connection from this useragent string, it
> means that
> > they *don't* want Wget to download from them, so I don't really think
> it's
> > the case to change this default string.
> >
> That's not always the case though. I know some mirrors would allow
> wget's with user defined, even if defined to a generic "Gentoo User
> Downloading Agent", but don't allow blank connections at all. I think
> the suggestion was whether there could be a way to set this default for
> portage.

And the response above yours was that wget does not make blank
connections, and therefore there is no need to set a default for
portage.

$ wget -q -d -O /dev/null http://1.1.1.1/
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.10 on linux-gnu.

Created socket 4.
Releasing 0x08084498 (new refcount 0).
Deleting unused 0x08084498.

---request begin---
GET / HTTP/1.0
User-Agent: Wget/1.10
Accept: */*
Host: 1.1.1.1
Connection: Keep-Alive

---request end---
...

--
( Georgi Georgiev ( When all else fails, EAT!!! (
) chutz@gg3.net ) )
( +81(90)2877-8845 ( (