Quantcast

download.opensuse.org vs software.opensuse.org

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

download.opensuse.org vs software.opensuse.org

Malte Gell-3
Hi there,

why does software.opensuse.org enjoy SSL, while download.opensuse.org
doesn´t?

best regards
M
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Marcus Meissner
On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
> Hi there,
>
> why does software.opensuse.org enjoy SSL, while download.opensuse.org
> doesn´t?

software.opensuse.org is entirely hosted on our servers.

download.opensuse.org is to a large degree only a redirector to our
mirrors.

I think that the core repodata that is always delivered from download.opensuse.org
should probably be https served though. I will see if I get that implemented.

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

don't follow the https'ers off the cliff... ;-)

L A Walsh
Other than obedience to google, what purpose does encrypting open source
linux
distro binaries & source serve?

https makes most content uncacheable, and I know I've saved 700MB in
Suse disc images in my cache that wouldn't have been saved with https
for most people.  On top of that, https slows down transfer and raises
latencies.

Please reconsider whether https is really needed for "download" or
"software".  It's not like either is serving sensitive information
and I really hate to see another sheep march to google's tune (when
they  want it to prevent you from selective ad filtering.



Marcus Meissner wrote:

> On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
>  
>> Hi there,
>>
>> why does software.opensuse.org enjoy SSL, while download.opensuse.org
>> doesn�t?
>>    
> download.opensuse.org
> so, Marcus
>  
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Lew Wolfgang
On 12/18/2016 04:20 PM, L.A. Walsh wrote:

> Other than obedience to google, what purpose does encrypting open source linux
> distro binaries & source serve?
>
> https makes most content uncacheable, and I know I've saved 700MB in
> Suse disc images in my cache that wouldn't have been saved with https
> for most people.  On top of that, https slows down transfer and raises
> latencies.
> Please reconsider whether https is really needed for "download" or
> "software".  It's not like either is serving sensitive information
> and I really hate to see another sheep march to google's tune (when
> they  want it to prevent you from selective ad filtering.

How about this one:  I've been unable to update flash-player on several Leap 42.2
boxes for more than a week.  Zypper/Yast2 trys to download
flash-player-24.0.0.186-2.2.x86_64.rpm
from pacman.inode.at, they get to 99%, then the connection is closed by
the peer.  I've resorted to locking the existing flash-player rpm so that I can
complete the other updates.

Since no one else is reporting similar issues, my latest hypothesis is that a
deep-packet-inspection intrusion prevention device somewhere on my connection
path is finding a false-positive hit in the binary and force-closing the
connection.  I've checked on our local IPS (Tippingpoint) and don't see
any hits, but there might be others farther upstream.  This is a very large
organization.

So if my hypothesis is correct, a TLS connection to pacman would allow
the updates to complete.

Regards,
Lew

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Lew Wolfgang
On 12/18/2016 05:09 PM, Lew Wolfgang wrote:

> On 12/18/2016 04:20 PM, L.A. Walsh wrote:
>> Other than obedience to google, what purpose does encrypting open source linux
>> distro binaries & source serve?
>>
>> https makes most content uncacheable, and I know I've saved 700MB in
>> Suse disc images in my cache that wouldn't have been saved with https
>> for most people.  On top of that, https slows down transfer and raises
>> latencies.
>> Please reconsider whether https is really needed for "download" or
>> "software".  It's not like either is serving sensitive information
>> and I really hate to see another sheep march to google's tune (when
>> they  want it to prevent you from selective ad filtering.
>
> How about this one:  I've been unable to update flash-player on several Leap 42.2
> boxes for more than a week.  Zypper/Yast2 trys to download
> flash-player-24.0.0.186-2.2.x86_64.rpm
> from pacman.inode.at, they get to 99%, then the connection is closed by
> the peer.  I've resorted to locking the existing flash-player rpm so that I can
> complete the other updates.
>
> Since no one else is reporting similar issues, my latest hypothesis is that a
> deep-packet-inspection intrusion prevention device somewhere on my connection
> path is finding a false-positive hit in the binary and force-closing the
> connection.  I've checked on our local IPS (Tippingpoint) and don't see
> any hits, but there might be others farther upstream.  This is a very large
> organization.
>
> So if my hypothesis is correct, a TLS connection to pacman would allow
> the updates to complete.

BTW, I should have mentioned that I haven't had a chance to confirm my
hypothesis with tcpdump yet, maybe I can get to that tomorrow.

Regards,
Lew

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2016-12-19 02:14, Lew Wolfgang wrote:
> On 12/18/2016 05:09 PM, Lew Wolfgang wrote:


>> Since no one else is reporting similar issues, my latest
>> hypothesis is that a deep-packet-inspection intrusion prevention
>> device somewhere on my connection path is finding a
>> false-positive hit in the binary and force-closing the
>> connection.  I've checked on our local IPS (Tippingpoint) and
>> don't see any hits, but there might be others farther upstream.
>> This is a very large organization.
>>
>> So if my hypothesis is correct, a TLS connection to pacman would
>> allow the updates to complete.
>
> BTW, I should have mentioned that I haven't had a chance to confirm
> my hypothesis with tcpdump yet, maybe I can get to that tomorrow.

Try download the file manually with a browser.

- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlhXPUsACgkQja8UbcUWM1wWuQD/f5yxiR7j0ejJSlzEOL9KEKUs
777XrZ2drdUwHZNPwTABAJKvyPNYlUzh+AzE+QX4CinqlhpQTS+SoOv6K760zb12
=6A0L
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Lew Wolfgang
On 12/18/2016 05:52 PM, Carlos E. R. wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2016-12-19 02:14, Lew Wolfgang wrote:
>> On 12/18/2016 05:09 PM, Lew Wolfgang wrote:
>
>>> Since no one else is reporting similar issues, my latest
>>> hypothesis is that a deep-packet-inspection intrusion prevention
>>> device somewhere on my connection path is finding a
>>> false-positive hit in the binary and force-closing the
>>> connection.  I've checked on our local IPS (Tippingpoint) and
>>> don't see any hits, but there might be others farther upstream.
>>> This is a very large organization.
>>>
>>> So if my hypothesis is correct, a TLS connection to pacman would
>>> allow the updates to complete.
>> BTW, I should have mentioned that I haven't had a chance to confirm
>> my hypothesis with tcpdump yet, maybe I can get to that tomorrow.
> Try download the file manually with a browser.
>

Good suggestion Carlos.  I tried it with wget and got the same "connection closed
by peer" disconnect at 99%.  I then tried wget from my home system and it worked, of
course.  So I used scp to move the rpm to the hosts in question.

Proves my point:  maybe repo access should be via TLS, if caching proxies aren't
an issue.  Could both 80 and 443 be supported?

Regards,
Lew

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Marcus Meissner
In reply to this post by L A Walsh
Hi Linda,

Others mentioned it, but the core reason here is integrity of the software
you download.

While once you have a repository added the GPG key is known and imported,
the initial import of software repositories is tricky and needs to rely
on some form of man in the middle protection.

https is some form of solution here.

Ciao, Marcus
On Sun, Dec 18, 2016 at 04:20:23PM -0800, L.A. Walsh wrote:

> Other than obedience to google, what purpose does encrypting open source
> linux
> distro binaries & source serve?
>
> https makes most content uncacheable, and I know I've saved 700MB in
> Suse disc images in my cache that wouldn't have been saved with https
> for most people.  On top of that, https slows down transfer and raises
> latencies.
>
> Please reconsider whether https is really needed for "download" or
> "software".  It's not like either is serving sensitive information
> and I really hate to see another sheep march to google's tune (when
> they  want it to prevent you from selective ad filtering.
>
>
>
> Marcus Meissner wrote:
> >On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
> >>Hi there,
> >>
> >>why does software.opensuse.org enjoy SSL, while download.opensuse.org
> >>doesn�t?
> >download.opensuse.org
> >so, Marcus
>

--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <[hidden email]>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

L A Walsh
In reply to this post by L A Walsh
Jean-Christophe Baptiste wrote:
> Are you jocking?
> Dowloading an operating system not a sensitive operation?
> Software integrity, useless?
>
> Of course, there are, I need a proof that what I get has not been tampered.
----
        You already have it.  You have signatures on the rpms.  That's
what they are for.  Https was intended to provide protection from
snooping.  If you don't think large corporate ISP's can't purchase
root-certs, or more likely "subordinated root certs" (those have
already happened and only made public when the corps mis-handled
the certs and let them get swiped), you'd be naive.  

        On smaller scales, sites with multiple users/clients are already
likely to force internal clients to use a caching & filtering proxy to
access the outside web.  With that in place, they can install
site-local root certs on site-owned clients and require mobile clients (if
allowed), to install site-local root-certs in order to have access
to the outside web.  The large uptick in https usage has forced
sites not using MITM proxies to change policies.  

        Fortunately, both downloaded rpms and sites providing sensitive
tars provide signatures for both that provide tampering protection.
Not only do the sigs provide tamper protection during transit, but they
also provide tamper protection for rpms stored locally, months later.
 
> Client side, what browser would be caching a 700MB file anyway? It would
> serve no purpose.
----
        It does.  I've fetched 700+ MB images from opensuse and MS from
cache as long as 1-2 months after original download.  Seeing large
downloads complete at >100MB/s is a noticeable event.  Wherever possible,
I disable individual client and machine caches because they waste space.
Instead, I use one large cache on an opensuse machine.  Best speed
boosts are on interactive websites, where there is more content duplication.
 
        It's not common to find 700MB requests duplicated, but given
the long time that distro-images stay constant and the size of proxy
cache, its happened a few times.

        Regardless of the transport protocol, the integrity of
the downloaded images is still available by signature verification.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

L A Walsh
In reply to this post by Lew Wolfgang
Lew Wolfgang wrote:

> Since no one else is reporting similar issues, my latest hypothesis is
> that a
> deep-packet-inspection intrusion prevention device somewhere on my
> connection
> path is finding a false-positive hit in the binary and force-closing the
> connection.  I've checked on our local IPS (Tippingpoint) and don't see
> any hits, but there might be others farther upstream.  This is a very
> large
> organization.
>
> So if my hypothesis is correct, a TLS connection to pacman would allow
> the updates to complete.
---
    Why would you think that?  If it is a large corporation, some of them
have already been noted to have subordinated root-certs that would allow
them to perform MITM inspection.  I.e. TLS wouldn't stop inspection.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

L A Walsh
In reply to this post by Marcus Meissner
Marcus Meissner wrote:

> While once you have a repository added the GPG key is known and imported,
> the initial import of software repositories is tricky and needs to rely
> on some form of man in the middle protection.
>
> https is some form of solution here.
---
        I've seen sites use https for "login" but http for bulk
content.  I've seen ssh patches that allow unencrypted transfer
of bulk content (like using scp), but disallow unencrypted access
for interactive sessions -- for exactly the same reason -- the
encrypting of the connection noticeably slows down speeds with
the difference being more noticeable the faster the connection
gets.

        Though -- isn't it possible to offer *both* connection
types -- staying with whatever protocol the user connects with?

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Lew Wolfgang
In reply to this post by L A Walsh
On 12/19/2016 11:26 AM, L A Walsh wrote:

> Lew Wolfgang wrote:
>> Since no one else is reporting similar issues, my latest hypothesis is that a
>> deep-packet-inspection intrusion prevention device somewhere on my connection
>> path is finding a false-positive hit in the binary and force-closing the
>> connection.  I've checked on our local IPS (Tippingpoint) and don't see
>> any hits, but there might be others farther upstream.  This is a very large
>> organization.
>>
>> So if my hypothesis is correct, a TLS connection to pacman would allow
>> the updates to complete.
> ---
>    Why would you think that?  If it is a large corporation, some of them
> have already been noted to have subordinated root-certs that would allow
> them to perform MITM inspection.  I.e. TLS wouldn't stop inspection.
>

In this case they don't do MITM inspection, so my hypothesis stands.  TLS
would enable me to do on-line updates, without it I have to sneaker-net in
the rpm.  Sure, it's a minor problem now that I understand what's happening,
but it happened nevertheless, and it wasted hours of my time.

Regards,
Lew



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

Bugzilla from jc@phocean.net
In reply to this post by L A Walsh
Le 19/12/2016 à 20:22, L A Walsh a écrit :

> Jean-Christophe Baptiste wrote:
>> Are you jocking?
>> Dowloading an operating system not a sensitive operation?
>> Software integrity, useless?
>>
>> Of course, there are, I need a proof that what I get has not been tampered.
> ----
>     You already have it.  You have signatures on the rpms.  That's
> what they are for.  Https was intended to provide protection from
> snooping.  
I know that but as you say yourself, they serve two complementary purposes. I want HTTPS to download the media, otherwise the whole signature infrastructure is useless if I get a different operating system.


> If you don't think large corporate ISP's can't purchase root-certs, or more likely "subordinated root certs" (those have
> already happened and only made public when the corps mis-handled
> the certs and let them get swiped), you'd be naive.

I have worked for ISP and never heard of such a practice. So I may still be naive despite being paranoid by profession.
Note that generally the threat model of the people I work for is not the secret services.
But it may be a motivated and skillful offender (hacker, if you prefer). So, HTTPS matters.

>     On smaller scales, sites with multiple users/clients are already
> likely to force internal clients to use a caching & filtering proxy to
> access the outside web.  With that in place, they can install site-local root certs on site-owned clients and require mobile clients (if
> allowed), to install site-local root-certs in order to have access
> to the outside web.  The large uptick in https usage has forced
> sites not using MITM proxies to change policies.

Again I am surprised by your picture of companies. Not many do TLS interception, and when they do, then, what is the threat for a user like me downloading a OS media?
The threat is not the company, because otherwise you would be owned in many ways. The threat is a malicious insider, for instance.


>     Fortunately, both downloaded rpms and sites providing sensitive
> tars provide signatures for both that provide tampering protection.
> Not only do the sigs provide tamper protection during transit, but they
> also provide tamper protection for rpms stored locally, months later.

Again, different and complementary purpose, see above. I would also add: security in depth.
>
>> Client side, what browser would be caching a 700MB file anyway? It would serve no purpose.
> ----
>     It does.  I've fetched 700+ MB images from opensuse and MS from
> cache as long as 1-2 months after original download.  Seeing large downloads complete at >100MB/s is a noticeable event.  Wherever possible,
> I disable individual client and machine caches because they waste space.
> Instead, I use one large cache on an opensuse machine.  Best speed
> boosts are on interactive websites, where there is more content duplication.

Generally not, and fortunately as it would not make sense to waste that much space for a single file.
You may configure your local network as you want, but it cannot make a case against a security consensus.

I will stop here as I do not really want to debate on something that has been admitted by an entire security community for years.

It is not people copying Google. It is simply Google following best practices of the security industry.


signature.asc (860 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: don't follow the https'ers off the cliff... ;-)

L A Walsh
Jean-Christophe Baptiste wrote:
> I know that but as you say yourself, they serve two complementary purposes. I want HTTPS to download the media, otherwise the whole signature infrastructure is useless if I get a different operating system.
---
        If you get a different OS?  how's that?

>
> I have worked for ISP and never heard of such a practice. So I may still be naive despite being paranoid by profession.
----

First widely known instance:

https://freedom-to-tinker.com/2013/01/03/turktrust-certificate-authority-errors-demonstrate-the-risk-of-subordinate-certificates/

Mozilla acknowledging and stomping feet:

http://www.computerworld.com/article/2495053/desktop-apps/mozilla-moves-to-limit-risk-of-subordinate-ca-certificate-abuse.html

It's happened, it's acknowledged, Mozilla threatens actions, but can
only ask for administrative controls.  




--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Malte Gell-3
In reply to this post by Marcus Meissner
Am 18.12.2016 um 20:08 schrieb Marcus Meissner:

> (...)
> I think that the core repodata that is always delivered from download.opensuse.org
> should probably be https served though. I will see if I get that implemented.

Why not the whole stuff?
As a distributor you are in a unique position.
As we all know, (almost) all CAs are evil, you can´t trust them.
You could install a self signed/made certificate and distribute it via
Firefox update and ship it with the distribution!
This way you save money and don´t depend on malicious CAs :-) You´d have
a rock safe certificate.
No bad CA being the man in the middle.

best regards


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Susan Dittmar
Am 20.12.2016 um 14:41 schrieb Malte Gell:

> Am 18.12.2016 um 20:08 schrieb Marcus Meissner:
>
>> (...)
>> I think that the core repodata that is always delivered from download.opensuse.org
>> should probably be https served though. I will see if I get that implemented.
>
> Why not the whole stuff?
> As a distributor you are in a unique position.
> As we all know, (almost) all CAs are evil, you can´t trust them.
> You could install a self signed/made certificate and distribute it via
> Firefox update and ship it with the distribution!
> This way you save money and don´t depend on malicious CAs :-) You´d have
> a rock safe certificate.
> No bad CA being the man in the middle.

Yes and no. Not everyone uses SUSE products exclusively, and
self-installed browsers will not know about the self-signed certificate.
Additionally, everyone who wants to start using SUSE products will have
to make an initial download without SUSE-modified software.

Susan
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Marcus Meissner
In reply to this post by Malte Gell-3
On Tue, Dec 20, 2016 at 02:41:03PM +0100, Malte Gell wrote:

> Am 18.12.2016 um 20:08 schrieb Marcus Meissner:
>
> > (...)
> > I think that the core repodata that is always delivered from download.opensuse.org
> > should probably be https served though. I will see if I get that implemented.
>
> Why not the whole stuff?
> As a distributor you are in a unique position.
> As we all know, (almost) all CAs are evil, you can´t trust them.
> You could install a self signed/made certificate and distribute it via
> Firefox update and ship it with the distribution!
> This way you save money and don´t depend on malicious CAs :-) You´d have
> a rock safe certificate.
> No bad CA being the man in the middle.

The openSUSE mirror infrastructure is largely volunteer ftp sites all around
the world, this rules out doing it all over https ;)

For the SUSE Linux Enterprise products we pay to use a CDN that handles HTTPS with
suse.com specific certificates.


The good thing is that the YUM repodata is GPG integrity checked, when you get
the correct key and repomd.xml, the rest is integrity checked with SHA256 signatures.

Being a trustworthy CA itself is hard. Of course one could limit it to repository
handling, then this would be easier...

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Bugzilla from admin@different-perspectives.com
It all seems a bit strange to me.  I’d ask what’s the threat you’re defending against?

The signed RPMs mean they can’t be interfered with, so there’s only two other things: the metadata which describes the repository and the RPMs; and the requests you’re sending.

Using HTTP for the RPMs allows the CDNs to be efficient, reducing the load on the servers.  HTTPS prevents that for no benefit as most people get the downloads from a local mirror, which could be corrupted directly.
There’s an argument for protecting the metadata from interference.

I’m not paranoid enough to worry about someone knowing what software I have loaded on my machines, and there’s no indication in it of which machines have which software.

So, what’s the problem / fear?

Yours
David

p.s. for a self-signed CA, how do you securely distribute the root certificate to all the users everywhere in the world?--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: download.opensuse.org vs software.opensuse.org

Eoin Kirwan-3
In reply to this post by Marcus Meissner
On Tuesday 20 December 2016 3:24:47 P.M. GMT Marcus Meissner wrote:
>
> The openSUSE mirror infrastructure is largely volunteer ftp sites all around
> the world, this rules out doing it all over https ;)

Hi Marcus,

The thing which concerns me is the ISOs - there are good reasons to have the
mirrors use HTTP, but the checksums used to check the integrity of the ISOs
should be downloaded over HTTPS from a verified source, bandwidth requirement
for this is very low.

I am presuming that there is inbuilt trust for the official repo signatures - I
don't recall ever being asked to accept a signing key except when adding a
community or other unofficial repo - so all is good once the integrity of the
ISO used to install the OS is guaranteed. We then know that updates and
additional packages are signed with a trusted key, at least for officially
supported packages.

This has come up before :)

----------  Forwarded Message  ----------

Subject: Re: [opensuse-security] Why no SSL for download.opensuse.org ?
Date: Sunday 7 July 2013, 1:11:08 A.M. GMT
From: [hidden email]
To: [hidden email]

On Sat 06 Jul 2013 10:34:45 Malte Gell wrote:

> We have learned how much effort governments take to control and monitor
> the Internet. With this in regard, wouldn´t it make sense to switch
> download.opensuse.org to SSL? I know, rpm packages are signed with
> GnuPG, but if you add a new repo an attacker still is able to give you a
> forged GnuPG key and a forged repo, not the repo you actually tried to
> subscribe to. Thus, GnuPG signing of rpm does not prohibit man in the
> middle attacks. I think SSL for download.opensuse.org would give more
> safety to people living in authoritarian regimes who want to download
> openSUSE software.
>
> Malte

The downloads themselves don't need to be SSL. Nobody should really trust a
large download without a checksum or some other sort of error checking. Many
people use torrents now anyway, and often they're more reliable. But the
openSUSE web page with the checksums for the downloads should absolutely be
SSL. This should be easy to do.

Regards,

Eoin



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Loading...