| didrocks | infinity: hey! I'm just starting to look at the upstart/upstart-bin/upstart-sysv separation. There is something I want to discuss with pitti before we go on on that topic | 07:16 |
|---|---|---|
| didrocks | infinity: the issue is about the "halt/poweroff/reboot…" bins | 07:16 |
| didrocks | as if you boot with another init, you expect to have the right binaries used of course | 07:17 |
| didrocks | and right now, they are in the upstart package and systemd-sysv | 07:17 |
| didrocks | not sure this worth having halt.upstart for instance | 07:17 |
| didrocks | so, it seems we need a wider discussion to see in which direction we should go | 07:18 |
| Ukikie | Might want to take into consideration users that do init=/sbin/upstart (as this is easy with grub2 now) | 07:21 |
| didrocks | Ukikie: that's exactly what we are talking about with this newer split | 07:24 |
| didrocks | (and that's the reason why we did that grub2 patch) | 07:25 |
| * Ukikie hides. | 07:25 | |
| didrocks | ;) | 07:25 |
| oSoMoN | Good morning release team! | 09:38 |
| oSoMoN | could someone please review bug #1433141 and advise? It’s being validated by the QA team, will shortly be ready to land, but needs an ack from you | 09:38 |
| ubot93 | bug 1433141 in webbrowser-app (Ubuntu) "[FFe] Bottom-edge gesture to open tabs list in the browser application" [Undecided,New] https://launchpad.net/bugs/1433141 | 09:38 |
| === doko_ is now known as doko | ||
| bdmurray | slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phasing-link/+merge/253720 | 17:33 |
| === Termana is now known as Guest54467 | ||
| bdmurray | infinity: it looks like it'd be a good idea to get dpkg version 1.17.24 into Vivid. What needs to happen for that? | 19:15 |
| bdmurray | I'm referring to the "Disable dependency checks on trigger processing." change in it. | 19:20 |
| === Termana is now known as Guest61277 | ||
| infinity | bdmurray: I'll be merging it soon. | 19:43 |
| bdmurray | infinity: okay, thanks! | 19:45 |
| bdmurray | infinity: Do you think I should won't fix the bugs created by trigger loops? | 19:55 |
| infinity | bdmurray: I think they're worth investigation. | 19:56 |
| infinity | bdmurray: Not in utopic, but in trust->vivid (and, eventually, 14.04->16.04) upgrades, we should care. | 19:56 |
| bdmurray | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776910 I was reading the last comment there | 19:57 |
| ubot93 | Debian bug 776910 in apt "apt: upgrade from wheezy to jessie breaks in the middle" [Grave,Open] | 19:57 |
| bdmurray | Paragraphs 2 and 4 | 19:58 |
| infinity | bdmurray: Right, so what I mean by "we should care about trusty->vivid (and beyond)" is that we should only care about trigger cycle bugs found that are upgrading with dpkg 1.7.24 or higher. Which, if guillem did this right, should be 0. | 20:01 |
| infinity | bdmurray: But the feature may creep back in before 16.04, and we need to pay attention to that. | 20:01 |
| infinity | bdmurray: I'll merge today, though, so we can see how this affects new bugs. | 20:01 |
| infinity | bdmurray: Old ones, we can probably drop on the floor, if no one has the energy to re-test those upgrades. | 20:02 |
| bdmurray | infinity: I don't think the dpkg version necessarily gets recorded in these apport reports so I'll fixes that. | 20:02 |
| infinity | bdmurray: If we're not recording dpkg and apt version in all upgrade reports, that's a massive bug. | 20:02 |
| infinity | bdmurray: And python-apt, if update-manager or ubuntu-release-upgrader was in play. | 20:03 |
| bdmurray | python-apt will get caught in that case because its a dependency | 20:03 |
| slangasek | bdmurray: this retrace failed with missing symbols for libsystemd0 and libflac8, which is pretty bad; are these known-missing ddebs? https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2 | 20:16 |
| slangasek | bdmurray: also, that retrace failed, but neither systemd nor flac libs are in the stack so that's also bad :) | 20:17 |
| bdmurray | slangasek: known to me yes | 20:20 |
| slangasek | bdmurray: ah; libsystemd0 is in the list you sent me earlier, I see, but not libflac8. Anyway, how can we debug the retracing failure, given that it seems unrelated to the missing symbols? The crash in question was from testing libc from vivid-proposed on a vivid system, would that account for the retracer not knowing where to find the symbols? And can we extract a core file for manual retraci | 20:28 |
| slangasek | ng? | 20:28 |
| slangasek | though libc6 itself wasn't listed as having missing symbols hmm | 20:29 |
| slangasek | cjwatson: I've tried to enable arm64 builds for ubuntu-core, and it's failing with errors that look like a networking problem; would you know if there's anything particular to twombly that would prevent it from reaching ppas etc? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23106 | 20:33 |
| bdmurray | infinity: new apport uploaded | 20:33 |
| bdmurray | slangasek: I think we save cores for some failures to retrace let me double check | 20:34 |
| infinity | slangasek: It can obviously reach PPAs, it did so earlier in the build log. | 20:34 |
| slangasek | ah true enough | 20:35 |
| slangasek | but it's still failing with networking failures | 20:35 |
| infinity | Could have just been an intermittent hiccup. | 20:35 |
| slangasek | could be; retrying | 20:36 |
| slangasek | note fwiw that arm64 was the only arch that failed with this problem | 20:37 |
| infinity | slangasek: It's going to fail anyway, that linux-image package doesn't exist. | 20:37 |
| slangasek | well, that's ok | 20:37 |
| slangasek | those are bugs that clearly belong to the image :) | 20:37 |
| infinity | ... how does that work on any arch? | 20:39 |
| * infinity scratches his head. | 20:39 | |
| infinity | Oh, wait. linux-packages, not linux-flavours | 20:39 |
| infinity | Yeah, that should work. | 20:40 |
| infinity | I just can't read. | 20:40 |
| elfy | cyphermox: re the com32 bug you just added to - did you mean 13.04 or 14.04? | 20:42 |
| cyphermox | depends what you mean by what I mean? | 20:43 |
| * infinity laughs. | 20:43 | |
| cyphermox | writing a live USB from vivid to 13.04 fails to properly start | 20:44 |
| cyphermox | ... the splash will not show, you'll get that com32 erro | 20:44 |
| elfy | is that because it's all completely EOL? | 20:44 |
| elfy | unless you start fiddling with oldubuntu repos | 20:45 |
| cyphermox | it's just an example of what versions to use, it's because they don't have the same structure for syslinux | 20:45 |
| cyphermox | you could use 12.04 | 20:45 |
| elfy | ok :) just making sure ... | 20:45 |
| cyphermox | I mention 13.04 and 13.10 because IIRC that's where the difference was introduced | 20:46 |
| elfy | I did some tests so I could be sure that people could test jam Xubuntu recently - told them to install gnome-disks and use Disks ... | 20:46 |
| cyphermox | the exact versions don't matter as long as you use an older version of Ubuntu to write a very recent USB (ie. precise writing vivid), or the other way around | 20:46 |
| elfy | obviously all of those entailed a vivid image from trusty/utopic or vivid | 20:48 |
| cyphermox | elfy: since the SRU is for utopic only so far (I haven't tested trusty in a VM here yet, the changes were a bit more complicated), you'll want to use a precise iso for writing | 20:48 |
| elfy | and for Xubuntu you need to install one or the other ... | 20:48 |
| cyphermox | I'm not sure I follow | 20:49 |
| elfy | I'm rambling probably - we were after specific information - whatever you use to do USB stick has to be installed on Xubuntu - so I was looking for something that worked in all 3 scenario's | 20:50 |
| elfy | I'll wander off again and not confuse the issue further ;) | 20:51 |
| cyphermox | elfy: use dd if you're unsure | 20:51 |
| cyphermox | isn't usb-creator installed on xubuntu? | 20:52 |
| elfy | nope | 20:52 |
| elfy | oh - actually might be - never use it personally | 20:52 |
| elfy | cyphermox: didn't want to expose possible new people to getting dd wrong ... | 20:52 |
| cyphermox | ok | 20:53 |
| cyphermox | well yeah, getting it wrong is usually disastrous :) | 20:53 |
| elfy | :) | 20:53 |
| elfy | usb-creator's not on the manifest for us | 20:54 |
| cyphermox | no, doesn't look like it's included | 20:54 |
| cyphermox | might want to consider changing that :) | 20:54 |
| elfy | why? | 20:54 |
| elfy | I tell people to use Disks :) | 20:54 |
| cyphermox | fair enough | 20:55 |
| cyphermox | well you could still ask them to pull usb-creator-gtk when needed | 20:55 |
| cyphermox | but if Disks works.. | 20:55 |
| cyphermox | does Disks do a full copy? | 20:55 |
| elfy | cyphermox: for me at least I got positives using that when doing vivid images from 14.04/14.10/15.04 | 20:56 |
| elfy | restore image | 20:56 |
| cyphermox | ok, sounds like it's probably nearly the same thing as dd... or running dd in the background | 20:56 |
| elfy | doesn't make it very easy to deal with the stick afterwards - owned by root | 20:56 |
| elfy | yep - seems so | 20:57 |
| bdmurray | slangasek: so we don't save coredumps if RetraceOutdatedPackages is true and it is true if we are missing ddebs as apport mixes the two together | 20:57 |
| slangasek | infinity: failed again with the same error. not transient. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23110 | 20:58 |
| slangasek | bdmurray: hmm ok | 20:58 |
| bdmurray | We could start saving them though | 20:59 |
| slangasek | davmor2: is your media-hub crash with https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2 still available locally? | 21:00 |
| slangasek | davmor2: or is the problem reproducible? | 21:00 |
| slangasek | bdmurray: perhaps a good idea | 21:00 |
| infinity | slangasek: Curious. Investigating. | 21:00 |
| slangasek | does also show the problem is not specific to a single arm64 builder | 21:02 |
| infinity | slangasek: Yeah, going to reproduce it manually quickly to see WTF it's doing. | 21:03 |
| slangasek | ok | 21:03 |
| infinity | Oh, that traceback has the required info. | 21:06 |
| infinity | I was just blind on the first reading. | 21:06 |
| infinity | Or the first log had a less useful trace. | 21:06 |
| infinity | softwareproperties.ppa.PPAException: 'Error reading https://launchpad.net/api/1.0/~snappy-dev/+archive/image: [Errno 110] Connection timed out' | 21:06 |
| infinity | It's making API calls. | 21:06 |
| infinity | On the one hand, "ew", on the other hand, can get IS to fix. | 21:07 |
| slangasek | infinity: so you'll chase it up? | 21:07 |
| infinity | slangasek: Already on it. | 21:08 |
| slangasek | ta | 21:08 |
| infinity | slangasek: So, there may or may not be a cowboy in place that may or may not work (feel free to test), but the larger issue now has a ticket, RT#79768 | 22:10 |
| === Termana is now known as Guest90425 | ||
| infinity | slangasek: FWIW, I can make an 'openssl s_client' connection from that network to {api.,}launchpad.net:443 now, so it should work. | 22:16 |
| infinity | slangasek: Hah, the api call worked and I bet it's now going to fail on contacting keyserver.ubuntu.com | 22:20 |
| infinity | slangasek: Also, who thought this was a sane thing to do in an image build? | 22:20 |
| wgrant | Ew | 22:20 |
| wgrant | ew | 22:20 |
| infinity | wgrant: Yes, ew. | 22:21 |
| infinity | wgrant: I said that very same thing 14 minutes ago. | 22:21 |
| infinity | Yup, there it goes failing on the keyserver. | 22:22 |
| infinity | Rename it to the more domain-specific EXTRA_PPAS (which is now a | 22:25 |
| infinity | space-separated sequence of <ppa-owner>/<ppa-name> pairs), and fetch | 22:25 |
| infinity | signing keys for those from Launchpad using python3-software-properties. | 22:25 |
| infinity | -- Colin Watson <cjwatson@ubuntu.com> Mon, 19 May 2014 15:28:35 +0100 | 22:25 |
| infinity | wgrant: Hey, don't you employ that guy now? :) | 22:25 |
| wgrant | Heh | 22:26 |
| infinity | wgrant: You know, on second thought, the datacentre is probably the only place in the world where add-apt-repository isn't a massive security hole, so maybe it's not that "ew". :P | 22:36 |
| infinity | wgrant: Speaking of, could we close that massive security hole by serving the actual public keys via https://api.lp.net instead of just fingerprints? | 22:39 |
| infinity | (Sure, it still means trusting the lp.net SSL cert, but that beats a plain HTTP connection to a keyserver) | 22:40 |
| wgrant | infinity: I thought the massive security hole was fixed years ago. | 22:40 |
| wgrant | It's meant to now download into a temporary keyring by fingerprint, then verify the fingerprint before importing into the main keyring. | 22:41 |
| infinity | wgrant: Verify it against what? | 22:41 |
| darkxst | infinity, hey, can you bump space on gnome3-staging ppa up a bit? sitting at 92% currently | 22:41 |
| wgrant | infinity: The fingerprint from the LP API. | 22:41 |
| infinity | wgrant: Still vulnerable to a fingerprint collision, since it's not the actual public key we're getting via a secure source. | 22:42 |
| wgrant | infinity: Fingerprint, not ID. | 22:42 |
| wgrant | If someone manages to collide fingerprints the entire world is broken and we should probably just move into caves. | 22:42 |
| infinity | wgrant: Oh, well, less bad then, certainly. | 22:42 |
| infinity | wgrant: Still seems like an odd runaround, since I assume LP has knowledge of the keys somewhere anyway. | 22:43 |
| wgrant | Colliding fingerprints requires a good SHA-1 preimage attack. | 22:43 |
| wgrant | infinity: LP just uses keyserver.internal. | 22:43 |
| wgrant | It doesn't store the keys themselves. | 22:43 |
| infinity | wgrant: Oh. | 22:43 |
| infinity | wgrant: Well, I guess ppamaster has them all, but yeah, just on disk. | 22:44 |
| wgrant | Well, sure, but they're well-defended given that they're private keys... | 22:44 |
| * infinity nods. | 22:44 | |
| wgrant | The appservers cannot see them! | 22:44 |
| infinity | Right, if this has been sorted to use fingerprints, I care less. | 22:44 |
| wgrant | https://launchpad.net/bugs/1016643 | 22:44 |
| ubot93 | Launchpad bug 1016643 in apt (Ubuntu Precise) "add-apt-repository downloads gpg key in an insecure fashion" [High,Triaged] | 22:44 |
| infinity | I just saw "whee, downloading a key by ID from an insecure source" and didn't like what I saw. :P | 22:45 |
| wgrant | (really the bug is in gpg, which should allow secure retrieval) | 22:46 |
| wgrant | That is, it should verify the fingerprint matches what it requested. | 22:46 |
| infinity | We could also default to hkps instead of hkp. | 22:47 |
| infinity | If we're already trusting Canonical SSL certs in this scenario for the LP API, then a cert on the keyserver would be the same level. | 22:47 |
| wgrant | That provides no value except for preventing someone from watching what you're doing. | 22:47 |
| wgrant | OpenPGP keys are cryptographically verifiable in other ways, and we should do that without relying on a secure transport. | 22:47 |
| wgrant | If it requested by key ID from a secure keyserver, I could still upload a colliding key and it will trust it because HTTPS. | 22:48 |
| infinity | Sure. I'm definitely no cryptographer. | 22:48 |
| infinity | But even a fingerprint is less good than the whole public key, one would assume. Despite, as you say, it being hard to collide. | 22:48 |
| wgrant | We can verify the fingerprint, and that is secure unless someone has a secret SHA-1 preimage attack, so we should do that. | 22:48 |
| infinity | Oh, fair point on the ID collision. keyserver.ubuntu.com is publically modifiable, I forget about that detail. | 22:49 |
| wgrant | OpenPGP should probably grow SHA-256 fingerprints, though for ECC keys it could also probably print them directly. | 22:50 |
| wgrant | But even MD5 isn't seriously broken for key fingerprinting purposes. | 22:51 |
| infinity | Really, fingerprints seem more for human consumption than computers, though. | 22:51 |
| wgrant | I wouldn't use it, but there are no huge known weaknesses so far. | 22:51 |
| wgrant | The fingerprint is just the SHA-1 of the public key. | 22:52 |
| wgrant | Just as we use the SHA-1 of Packages to verify it. | 22:52 |
| infinity | I'll take your word on the collision-being-hard thing, since you've clearly read more than I have, but it just seems like simple logic that if you could give a computer the public key, you should, cause why intentionally weaken it, even if only by a little bit? | 22:52 |
| wgrant | (except you don't usually compare Packages files, as they're OpenPGP-signed... by a key that your OS trusts or that you've verified the SHA-1 of!) | 22:52 |
| wgrant | s/Packages files/Packages files' SHA-1s/ | 22:53 |
| wgrant | SHA-1 is becoming problematic for generic crytographic uses, but in this context it is a good many years away from being an issue. | 22:54 |
| infinity | And fear of Sha1 is why all the Packages/Sources files now have Sha256, I thought. :P | 22:54 |
| wgrant | Yes! | 22:54 |
| wgrant | But that's because a collision attack is plausible there. | 22:54 |
| wgrant | That's why modern keys use SHA-2 defaults for signatures that they generate. | 22:55 |
| wgrant | MD5 is very vulnerable to collision attacks, and SHA-1 looks like it will fall soon. | 22:55 |
| wgrant | But both are still fine against preimage and second-preimage attacks, and those aren't relevant for key fingerprints. | 22:55 |
| infinity | I imagine this all relates to math I forgot somewhere in my early 20s. | 22:56 |
| infinity | Intentionally. | 22:56 |
| wgrant | Collision == choose two inputs that hash to one output | 22:56 |
| infinity | Yes, I know. :P | 22:56 |
| wgrant | Preimage == choose one input that hashes to the same as a given input | 22:56 |
| wgrant | Second-preimage == choose one input that hashes to a given output | 22:57 |
| wgrant | The infamous PS3 MD5 collision was only possible because they were able to choose most of the data in both inputs, and were able to guess everything they couldn't choose. | 22:57 |
| infinity | Ahh, so the contention is that sha1 is vulnerable to accidental collisions just because the search space is small and the number of files in the world is large, but actually crafting an intentional and useful collision (like another PGP key) is still hard/impossible. | 22:58 |
| wgrant | infinity: Not accidental collisions. | 22:59 |
| wgrant | The contention is rather that collision attacks aren't relevant for public key fingerprints, since the attacker has no input into your public key (unless they compromise your RNG, in which case they probably have your private key anyway), so no collision attack is possible. Combine that with the very low risk of a practical SHA-1 (second-)preimage attack in the next couple of decades, and SHA-1 for | 23:02 |
| wgrant | fingerprints looks not particularly fatal. | 23:02 |
| wgrant | Certainly not something I'd pick today, but not a problem for a good long time. | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!