Re: More LiveCD space optimizations
[ compression related discussion removed ] So maybe we can save some MB with better compression, but we can save more by not including files at all. Of course this requires inspection of the packages included on the liveCD. In the past we did identify some issues and did add some diagnostics to the live CD build logs [1]. Of course you can't run anything and lengthen the live CD build, but some additional diagnostics maybe could be run. In the past we did see wasted space: - Packages which should not be on the CD. Some things should not be on the CD at all. Looking at the current live CD log, a typical candidate for this would be tcl8.4. Why is it there, and how can it be avoided? - Large doc directories. If a package becomes too large, maybe it is worth to split a package into foo and foo-doc, and not ship foo-doc on the CD (yes there are other ideas not to ship doc dirs at all). See python-couchdb for an example. The API documentation does not need to be on the live CD. The same may be true for other python packages. - Localized help images. You cannot just remove the images from an application's help, but in the past we did ship all these localized help images on the CD. CC'ing Martin, don't know the current status. However it looks like there are some xml files which maybe should be part of the language packs. - Duplicate files. While this is not that important on the live CD, it's important for the alternate CDs. Looking at the list of duplicate files, I see a lot of potential in: - all the mono packages and libraries - broken build systems shipping doc files in every binary package. see the upstream changelog.gz files (e.g. gnome and OOo). - firefox and xulrunner shipping duplicate .js files - package specific stuff (libc6-dev having some identical libs in /usr/lib/xen). - you may see and find more if you are familiar with a particular package. There is potential in saving space with better compression, but IMO you can even save more with closely looking what goes on the CD (where we currently don't do a good job). The good thing is that both approaches don't exclude each other. Matthias [1] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/latest/livecd-20101007-i386.out -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: More LiveCD space optimizations
2010-10-08 09:54 GMT Matthias Klose d...@ubuntu.com: In the past we did see wasted space: - Packages which should not be on the CD. Some things should not be on the CD at all. Looking at the current live CD log, a typical candidate for this would be tcl8.4. Why is it there, and how can it be avoided? foo2zjs made APT install that package. $ aptitude why tcl8.4 i tk8.4 Depends tcl8.4 (= 8.4.16) $ aptitude why tk8.4 i foo2zjs Recommends tk8.4 I'm sure there will be other examples, though I'm not as familiar with the LiveCD's packages as you guys at Canonical. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wiki SSL
On Oct 8, 2010, at 8:38 AM, Phillip Susi wrote: wiki.ubuntu.com forces you to use an SSL connection via automatic redirect to https. Why does it do this, and can we stop that please? There is no reason for using SSL to access a public web site when you are not logged in. It only serves to slow things down, prevent caching, and put a lot more load on the server. There are some very good reasons to have the wiki on SSL. Lets say you are at a conference where a speaker suggests going to wiki.ubuntu.com to read a page about XYZ feature. Some nefarious person who hears this can very quickly setup a DNS cache poisoning to redirect those requests to his server where he rewrites the page to include directions to add a PPA where he has uploaded evil packages that take over peoples' machines. Yes its a wiki so this person could do that by logging in and changing it, but wiki pages have subscribers and so there will be at least some chance of early detection. With SSL, this will at least show some very serious warnings about the SSL certificate. Even if he just redirects from the http port on wiki.ubuntu.com to https on his evil server, he will have to change the name, and the attack has yet another chance of being thwarted. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wiki SSL
On Fri, Oct 8, 2010 at 8:02 PM, Clint Byrum cl...@ubuntu.com wrote: With SSL, this will at least show some very serious warnings about the SSL certificate. Even if he just redirects from the http port on wiki.ubuntu.com to https on his evil server, he will have to change the name, and the attack has yet another chance of being thwarted. Yes, but what protection does this bring if: * the speaker enters wiki.ubuntu.com in the browser (default to HTTP) * the attacker does NOT redirect to a SSL site and just presents a (malicious) HTTP page * the speaker has no clue that wiki.ubuntu.com should normally be on HTTPS I wasn't aware that wiki.ubuntu.com must be HTTPS. I may have noticed it at some point, but I couldn't say if it always was HTTPS or not and I don't think I'm alone. -- . ..: Lucian -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wiki SSL
On 10/8/2010 1:20 PM, Lucian Adrian Grijincu wrote: Yes, but what protection does this bring if: * the speaker enters wiki.ubuntu.com in the browser (default to HTTP) * the attacker does NOT redirect to a SSL site and just presents a (malicious) HTTP page * the speaker has no clue that wiki.ubuntu.com should normally be on HTTPS My thoughts exactly. This is an extraordinarily contrived reason to always use ssl. Not to mention that ANY site that says to add a repository hosted on some random server you have never heard of should probably cause you to think twice. If it would be that obvious to people watching changes to the wiki, it should be just as obvious to someone reading it. Now that I think about it though, why is the page not cached? Is it because the server is setting the no cache flag, or because the browser refuses to cache documents fetched with ssl? If the former, then changing that would help the matter quite a bit while still using ssl. The load on the server could also be reduced by using null encryption when sending to the client, or does it have to use the same encryption both directions? I suppose you do want any password the client sends to be encrypted. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wiki SSL
On Oct 8, 2010, at 11:39 AM, Phillip Susi wrote: On 10/8/2010 1:20 PM, Lucian Adrian Grijincu wrote: Yes, but what protection does this bring if: * the speaker enters wiki.ubuntu.com in the browser (default to HTTP) * the attacker does NOT redirect to a SSL site and just presents a (malicious) HTTP page * the speaker has no clue that wiki.ubuntu.com should normally be on HTTPS My thoughts exactly. This is an extraordinarily contrived reason to always use ssl. Not to mention that ANY site that says to add a repository hosted on some random server you have never heard of should probably cause you to think twice. If it would be that obvious to people watching changes to the wiki, it should be just as obvious to someone reading it. Right, though if that site is *delivered via ssl* and the cert is from a trusted organization, you can trust the source of that information.. if you click history you know you're getting the real history. So if the attacker did not redirect to SSL, then you are not on an SSL site, and you should be *suspicious*. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wiki SSL
On Oct 8, 2010, at 4:31 PM, Lucian Adrian Grijincu wrote: On Fri, Oct 8, 2010 at 10:09 PM, Clint Byrum cl...@ubuntu.com wrote: Right, though if that site is *delivered via ssl* and the cert is from a trusted organization, you can trust the source of that information.. if you click history you know you're getting the real history. So if the attacker did not redirect to SSL, then you are not on an SSL site, and you should be *suspicious*. I AM a person that has a very high regard towards security (I don't have the same password on two different sites, I notice when a HTTP site asks me for my password, I always check the URL of the website before entering my passwords, etc.) but I have not noticed until now that the wiki.ubuntu.com is always on HTTPS and I don't think I would have noticed when it would have loaded as HTTP. Whether or not you noticed, the point is that you have zero way to trust the HTTP sites, and at least some level of trust for HTTPS. I don't think anyone goes around poking every bit of info they can find about the authors that changed something in the history of a document. I'm sure I can go register the wiki user JomoBacon or IonoBacon and make some edits as him on a number of pages and all this always-HTTPS snake-oil won't save most users from anything. No, people don't do that. But its important that the capability is there. I see it more as a daily vitamin C supplement, not a cure-all. There are lots of things one can do to avoid problems, but one thing you can't do, is verify the source of an HTTP downloaded web page from the internet without some help. HTTPS, is just one way we can give you that help. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: More LiveCD space optimizations
Apologies for the previous attachment, it didn't have the addition for man-page symbolic links. I attach the proper one this time. - Louis ubuntu-opt.tar.gz Description: GNU Zip compressed data -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
