[00:39] <Logan_> lol, Vivid is already open?
[00:39] <Logan_> that's a quick turnaround
[00:59] <tumbleweed> not open yet, in freeze
[03:43] <slangasek> stgraber: wat. https://wiki.ubuntu.com/UbuntuDevelopers?action=diff&rev2=94&rev1=93 :)
[10:50] <Riddell> our torrrent files are really the iso files
[10:50] <Riddell> http://cdimage.ubuntu.com/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.torrent
[10:50] <Riddell> anyone know anything about those files?
[10:51] <Riddell> or maybe a task for sysadmins?
[10:53] <cjwatson> I think possibly sysadmin screwed up cloudfront redirects?  They're fine on the master system
[10:53] <cjwatson> cdimage@nusakan:~/cdimage/www$ file full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso*
[10:53] <cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso:         # ISO 9660 CD-ROM filesystem data 'Kubuntu 14.10 i386              ' (bootable)
[10:53] <cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.torrent: BitTorrent file
[10:53] <cjwatson> full/kubuntu/releases/utopic/release/kubuntu-14.10-desktop-i386.iso.zsync:   data
[10:53] <cjwatson> Can you wait a couple of hours until I'm in work properly and can track this down?
[13:05] <Mirv> unity 7.2.3+14.04.20140826-0ubuntu1 for trusty has had the last verifications done a few days ago. all in all 30 days in -proposed.
[13:11] <Riddell> cjwatson: I worked out that if you swap utopic for 14.10 in that torrent url it works so updated the website for that
[16:43] <wxlS5> We don't have any products in the daily manifest. Is that something you guys take care of or is that a flavor job?
[17:09] <teward> anyone on the SRU team I can poke/bother/annoy/question regarding a specific bug and whether or not it's even remotely SRUable?
[17:17] <rbasak> teward: don't ask to ask, etc.
[17:19] <teward> rbasak: true.  :P
[17:20] <teward> bah i have to find the bug again
[17:21] <teward> anyways, the default nginx configuration file has the SSL section commented out, but has SSLv3 in its ssl_protocols line for the example config.  While a lot of new users just uncomment those sections and use them as is, they usually don't change much there.  To that end, they open themselves up to the POODLE vuln.
[17:21] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1383379 was the bug I filed for this
[17:21] <ubot2> Launchpad bug 1383379 in nginx (Ubuntu Trusty) "nginx default config has SSLv3 enabled, makes sites using default config options vulnerable to POODLE" [Undecided,New]
[17:21] <teward> sec team said to check with SRU team for Trusty and Precise as to whether it gets included or even addressed
[17:21] <teward> (mdeslaur uploaded nginx to utopic that makes the change in the default configs, though, last minute, which was accepted)
[17:22] <teward> looking for guidance on whether SRU team would accept or not.
[17:22] <rbasak> One catch is that this will cause a conffile prompt when users pick up this update.
[17:23] <rbasak> (if they commented the section out, then that constitutes a change that dpkg won't want to overwrite)
[17:23] <teward> rbasak: +1
[17:23] <teward> that is a consideration point
[17:24] <rbasak> If a user doesn't already have SSL enabled (no conffile change), then I think the user is less likely to enable it in the future.
[17:24] <teward> to that end, if the decision is to NOT support the upload, and make the bug "won't fix" or something, that's fine, I blogged about the issue
[17:24] <teward> (and that's already aggregated on planet.u.c, and available to the world for recommendation of disabling SSLv3)
[17:24] <rbasak> If the user _has_ enabled SSL (conffile change), then the user will get a prompt. Which may be a reasonable thing to do, except that the user won't have any hint of _why_ he has the conffile prompt.
[17:25] <rbasak> (and the prompt will appear as just a change in a comment)