[Bug 856919] New: Establish a Standard for All Online Download Opensuse and Other Repositories
https://bugzilla.novell.com/show_bug.cgi?id=856919 https://bugzilla.novell.com/show_bug.cgi?id=856919#c0 Summary: Establish a Standard for All Online Download Opensuse and Other Repositories Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: All OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Download Infrastructure AssignedTo: lrupp@suse.com ReportedBy: secure@aphofis.com QAContact: lrupp@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Currently we employ what I like to call a 'smoke and mirrors' magic act at providing a standard Download for Online Updates known collectively as *download.opensuse.org/ and we do this via http:// traffic. Firstly can we establish a standard in using ftp:// traffic in lieu of http:// FTP traffic was innately created for the use of file transfer as it was faster in the scene it requires only an 8-bit channel string redundancy check. It also offers the ability to permit or deny site Execution, permit a resume of traffic if ALG scanning is employed or any low level disruption. If also offers protection of client or server via active and passive mode. We can even employ FTP/SSL if future requirements demand far safer traffic. All up its original design was to offer file transfer with inherent design protection and using far less resources to maintain or prevent an incomplete data stream. Somewhere we all forgot that but I would like to suggest we go back to it rather than http:// GET Secondly as we attempt to make the configuration of downloads a standard structure the reply URL from where the files actually come looks something like this example. This makes it impossible for any Netadmin to provide security exceptions to traffic download and the actual reply has no common logic to apply. The search for community repositories, their addition and auto insertion of late has been a bit hit or miss...see bug #855549 ftp5.gwdg.de/pub/opensuse/repositories/Emulators:/Wine/openSUSE_12.3 widehat.opensuse.org/repositories/Emulators:/Wine/openSUSE_12.3/repodata download.opensuse.org/repositories/Emulators:/Wine/openSUSE_12.3/repodata ftp.df.lth.se/pub/opensuse/repositories/server:/database/openSUSE_12.3/repodata mirror.tspu.ru/opensuse/repositories/server:/database/openSUSE_12.3/repodata ftp5.gwdg.de/pub/opensuse/repositories/server:/database/openSUSE_12.3/repodata ftp.df.lth.se/pub/opensuse/repositories/server:/database/openSUSE_12.3/repodata Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: If anything can we all please have the discussion as above as I certainly don’t have all the answers to create some logic out of 'smoke and mirrors'; however to maintain our principal logic we need to start a dialogue and work out how to create something far better and far more logical. I certainly think we need to look at wikimedia.org and as a matter of urgency use FTP/SSL for both our upload or replication to repositories as well as download of repositories. I know I should stay clear of the subject but a more secure cloud that currently offers us our Bugzilla Tools and Management may be a good undertaking. Expected Results: A safe and fast standard world wide from a secure cloud with secure replication of cloud repositories with standards of traffic type and URL I believe this is a bug as it is hampering our ability to provide standards of the reply URL making it a security nightmare for netadmins to permit online updates and downloads of huge amounts of data and a huge number of program files. An .rpm or .drpm is no more safe than an .exe or .dll or .cab and providing security for inbound data is currently a nightmare. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=856919
https://bugzilla.novell.com/show_bug.cgi?id=856919#c1
Lars Vogdt
Firstly can we establish a standard in using ftp:// traffic in lieu of http:// ?
The answer is: no, sorry. The reason behind this answer is the used tool: http://mirrorbrain.org/ and the missing ability of the FTP protocol to allow redirects.
Secondly as we attempt to make the configuration of downloads a standard structure the reply URL from where the files actually come looks something like this example.
Sorry, but even here I have to admit that we rely on public mirror administrators that host some content for openSUSE for free. They decide where to start the sync, what to sync and when. ...and where to place the files on their servers. Sometimes they need to follow some restrictions on their infrastructure, sometimes they integrate our directories into their environment.
If anything can we all please have the discussion as above as I certainly don’t have all the answers to create some logic out of 'smoke and mirrors';
To give you some information at hand before we start the discussion: * http://mirrorbrain.org/docs/ * http://en.opensuse.org/Mirror_Infrastructure * http://en.opensuse.org/openSUSE:Mirror_howto * http://mirrors.opensuse.org/ * ftp://ftp.suse.com/pub/people/lrupp/openSUSE/Summit/2013/MirrorBrain.pdf (or MirrorBrain.odp) I agree that using https might be an idea (please open a feature request for this - currently I only see https://features.opensuse.org/312047 ).
secure replication of cloud repositories with standards of traffic type and URL
As long as nobody starts to spend money/storage/bandwidth/hardware and time, I do not see the openSUSE distribution to be able to establish what you expressed in your statement.
An .rpm or .drpm is no more safe than an .exe or .dll or .cab and providing security for inbound data is currently a nightmare.
All our RPMs are signed by a private key. Especially if you stay on the official repositories and their RPMs, the system itself checks the signature and will warn any user about possible "man in the middle" attacks resp. broken RPMs. As DRPMs are just containing the missing parts to build a new RPM out of an old one, they also include not only the needed checksums each RPM requires, but also the signature that is needed to verify the RPM itself after the delta is applied. Please read the following information: * http://www.rpm.org/max-rpm/s1-intro-to-rpm-whats-in-package.html * http://www.rpm.org/max-rpm/ch-rpm-verify.html * http://www.rpm.org/max-rpm/ch-rpm-pgp.html * http://en.opensuse.org/openSUSE:Libzypp_metadata_signature
I believe this is a bug as it is hampering our ability to provide standards of the reply URL making it a security nightmare for netadmins to permit online updates and downloads of huge amounts of data and a huge number of program files.
Nobody stops a good netadmin to check out the best openSUSE mirror in his area here on this page: http://mirrors.opensuse.org/ and start to mirror the content he needs from this mirror for his users. He can also become an own mirror admin which allows him not only to participate in distributing openSUSE, but also to get always the latest updates for his users. All over all your bug report combines some valid questions and comments with some things that sound much more like a rant of an uninformed user to me. I admit that this put me off quite a bit. Maybe you should investigate some time into reading the information provided in the links above and then come up and create feature requests at https://features.opensuse.org/ if you like to establish something new or bug reports at https://bugzilla.novell.com/ if you encountered a real problem with the current setup that should be fixed. Leaving it up to you to decide how to proceed from here - therefor setting needinfo. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=856919
https://bugzilla.novell.com/show_bug.cgi?id=856919#c2
Scott Couston
https://bugzilla.novell.com/show_bug.cgi?id=856919
https://bugzilla.novell.com/show_bug.cgi?id=856919#c3
--- Comment #3 from Scott Couston
participants (1)
-
bugzilla_noreply＠novell.com