[gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Petteri Räty]

-----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: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]


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 ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Petteri Räty]

-----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: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Lars Strojny]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] the default FETCHCOMMAND with broken ssl certificates

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

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   (                                               (

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]