As the subject says, i think 'useNoSSLForPackages' is rather badly conceived. Whenever i see an option that has the word "No" or "Don't" in it, alarm bells ring in my head.
This is a recipe for confusion. Can we get future versions of the option renamed to "useSSLForPackages"? (I would make it off by default, too, since many packages are rather large and some of us still pay a lot for bandwidth.)
I suppose i should bugzilla this...
On Sat, Sep 27, 2003 at 04:39:52PM +1000, Paul Gear wrote:
As the subject says, i think 'useNoSSLForPackages' is rather badly conceived. Whenever i see an option that has the word "No" or "Don't" in it, alarm bells ring in my head.
This is a recipe for confusion. Can we get future versions of the option renamed to "useSSLForPackages"?
Is this really enough of a reason to break compatibility with old config files?
(I would make it off by default, too, since many packages are rather large and some of us still pay a lot for bandwidth.)
I would expect the effect of SSL on bandwidth use to be minimal. If you really want to reduce bandwidth, I think there would be more gains if some RPM packages were compressed using bzip2 rather than gzip.
Besides, SSL provides real security. For instance, the fact that SSL is enabled by default was a good defense against this hole: https://rhn.redhat.com/errata/RHSA-2003-255.html
-Barry K. Nathan barryn@pobox.com
On Sat, 27 Sep 2003, Barry K. Nathan wrote: [...]
Besides, SSL provides real security. For instance, the fact that SSL is enabled by default was a good defense against this hole: https://rhn.redhat.com/errata/RHSA-2003-255.html
Note that SSL is just a tool. It depends heavily either on Certificate Authorities to do their job properly, or "opportunistic" self-signed certificate exchange working. It gives close to zero protection if you connect to a HTTPS site X for the first time, and you don't have any reference to the certificate the site X is using.
Barry K. Nathan wrote:
... I would expect the effect of SSL on bandwidth use to be minimal. If you really want to reduce bandwidth, I think there would be more gains if some RPM packages were compressed using bzip2 rather than gzip.
It has a huge effect, for the simple reason that it is *non-cacheable*. If you have multiple systems that need the packages, you have to turn on useNoSSLForPackages if you don't want to download every package for every machine.
Paul Gear said:
Barry K. Nathan wrote:
... I would expect the effect of SSL on bandwidth use to be minimal. If you really want to reduce bandwidth, I think there would be more gains if some RPM packages were compressed using bzip2 rather than gzip.
It has a huge effect, for the simple reason that it is *non-cacheable*. If you have multiple systems that need the packages, you have to turn on useNoSSLForPackages if you don't want to download every package for every machine.
I would trust a local mirror of updates.redhat.com and the "--packagedir" option for up2date more than I would trust a proxy cache.
On Sat, Sep 27, 2003 at 09:41:55PM -0400, William Hooper wrote:
I would trust a local mirror of updates.redhat.com and the "--packagedir" option for up2date more than I would trust a proxy cache.
Not to mention, Red Hat also has an RHN proxy server available for purchase. AFAIK that's their official solution for local caching: http://www.redhat.com/software/rhn/management/table/
Or you can locally mirror updates.redhat.com and serve that out with Current (that's what I'm doing -- it lets me add custom packages of my own to the channel, too): http://current.tigris.org/
-Barry K. Nathan barryn@pobox.com
Barry K. Nathan wrote:
On Sat, Sep 27, 2003 at 09:41:55PM -0400, William Hooper wrote:
I would trust a local mirror of updates.redhat.com and the "--packagedir" option for up2date more than I would trust a proxy cache.
I don't understand why a mirror should be more /trustworthy/ than a proxy server. Perhaps more secure in that you control when files get deleted, but /trust/?
... Or you can locally mirror updates.redhat.com and serve that out with Current (that's what I'm doing -- it lets me add custom packages of my own to the channel, too): http://current.tigris.org/
I used to mirror the updates site, but i found that it didn't save bandwidth, because so many packages were updated that i don't use. (Check out the package sizes the next time an emacs errata is released. :-)
Using a proxy server on my local LAN gives me the best savings in bandwidth (only the packages i actually use are downloaded), and is easier to manage, not to mention the fact that i use it anyway for my client PCs.
Barry K. Nathan wrote:
On Sat, Sep 27, 2003 at 04:39:52PM +1000, Paul Gear wrote:
As the subject says, i think 'useNoSSLForPackages' is rather badly conceived. Whenever i see an option that has the word "No" or "Don't" in it, alarm bells ring in my head.
This is a recipe for confusion. Can we get future versions of the option renamed to "useSSLForPackages"?
Is this really enough of a reason to break compatibility with old config files?
No, but it's a good reason to deprecate the badly-named options and provide new ones. It can be done in a backwards-compatible manner.
Paul Gear said:
Barry K. Nathan wrote:
On Sat, Sep 27, 2003 at 09:41:55PM -0400, William Hooper wrote:
I would trust a local mirror of updates.redhat.com and the "--packagedir" option for up2date more than I would trust a proxy cache.
I don't understand why a mirror should be more /trustworthy/ than a proxy server. Perhaps more secure in that you control when files get deleted, but /trust/?
[snip]
Using a proxy server on my local LAN gives me the best savings in bandwidth (only the packages i actually use are downloaded), and is easier to manage, not to mention the fact that i use it anyway for my client PCs.
Trust meaning that I know the package is there. As you point out, your client PCs are using the same proxy. Unless you have an extremely large cache the updates won't be on the proxy server for a long period of time. With a local mirror, I can set up a new machine and be assured that all the updates, no matter how long ago they were released, are already local. To each his own, really.
On Sat, Sep 27, 2003 at 04:39:52PM +1000, Paul Gear wrote:
As the subject says, i think 'useNoSSLForPackages' is rather badly conceived. Whenever i see an option that has the word "No" or "Don't" in it, alarm bells ring in my head.
heh, yeah. I think it was supposed to be "useNoSSLServerURLForPackages". But then, I've never been one for picking good names for things.
This is a recipe for confusion. Can we get future versions of the option renamed to "useSSLForPackages"? (I would make it off by default, too, since many packages are rather large and some of us still pay a lot for bandwidth.)
Possibly.
As mentioned, it was origianally added to up2date to allow people to setup squid caches (with a suitable tweaked squid config to cache big "objects"...)
Adrian
Adrian Likins wrote:
On Sat, Sep 27, 2003 at 04:39:52PM +1000, Paul Gear wrote:
As the subject says, i think 'useNoSSLForPackages' is rather badly conceived. Whenever i see an option that has the word "No" or "Don't" in it, alarm bells ring in my head.
heh, yeah. I think it was supposed to be "useNoSSLServerURLForPackages". But then, I've never been one for picking good names for things.
That's not the point: what i'm asking for is that all options should be stated in the positive, not the negative. If you want to use SSL by default (which i think you shouldn't, but that doesn't matter for the purposes of this discussion), you should make an option called 'useSSLForPackages' and set it to 1. Don't call it 'useNoSSLForPackages' and set it to 0 - that means that people have to negate it in their head. The same goes for:
noBootLoader=0 (should be BootLoader=1)
noReboot=0 (should be Reboot=1, or perhaps 'RebootIfNecessary', since just reboot by itself might give the impression that reboots are *always* done)
noReplaceConfig=0 (should be ReplaceConfig=1)
... As mentioned, it was origianally added to up2date to allow people to setup squid caches (with a suitable tweaked squid config to cache big "objects"...)
That's exactly why i'm asking for SSL to be off by default. It serves no purpose (now that the GPG signature verification bug is fixed), and it makes things behave in an unexpected manner when sending the connection through a proxy.
-
Adrian Likins -
Barry K. Nathan -
Paul Gear -
Pekka Savola -
William Hooper