| === doko_ is now known as doko | ||
| === Guest68049 is now known as rcj | ||
| === rcj is now known as Guest36844 | ||
| cyphermox | hi, could someone please review upstart-watchdog in the NEW queue? | 14:55 |
|---|---|---|
| xnox | cyphermox: the sheer name scares me! =) | 14:57 |
| cyphermox | xnox: hehehe :) | 14:58 |
| cyphermox | as it should | 14:58 |
| ogra_ | we need to have something consuming all that dogfood we invest ;) | 15:00 |
| ogra_ | hmm, could anyone let mit out of proposed so i can re-generate the meta package properly ? | 15:04 |
| ogra_ | *mir | 15:04 |
| === charles_ is now known as charles | ||
| ogra_ | since the new packages are not in the archive atm i cant get the ubuntu-touch-meta update script have them recognize yet | 15:05 |
| xnox | ogra_: invoke editor ;-) | 15:09 |
| cjwatson | Letting mir out of -proposed isn't a manual thing, as you well know! | 15:12 |
| cjwatson | Regenerate the metapackage first, by hand if necessary. | 15:13 |
| cjwatson | The update script isn't the be-all and end-all ... | 15:13 |
| cjwatson | I'm not going to override proposed-migration just to avoid manual work regenerating the metapackage. | 15:13 |
| ogra_ | hmm, k | 15:17 |
| ypwong | arges, I think you have reviewed bug 1329262, may I know what is blocking it to be released to -updates? | 15:25 |
| ubot2 | bug 1329262 in Ubuntu Kylin trusty "plymouth message --text doesn't work with ubuntukylin-theme" [Critical,Triaged] https://launchpad.net/bugs/1329262 | 15:25 |
| arges | ypwong: hi. let me look | 15:25 |
| arges | ypwong: so 1.0.1 in trusty-proposed is what fixes that bug? It seems like the changelog message didn't include that bug (which is why it was missed) | 15:26 |
| arges | ypwong: if you can confirm thats what fixed the bug I can release that into -updates. | 15:27 |
| ypwong | arges, I can see the bug # in https://launchpad.net/ubuntu/+source/ubuntukylin-theme/1.0.1 | 15:31 |
| arges | ypwong: hmm. Ok : ) well maybe the pending SRU page didn't pick it up for some reason. I see that everything is verified, so I'll release it. | 15:32 |
| ypwong | arges, thank you :)\ | 15:32 |
| arges | ypwong: ok done. thanks for bringing this to my attention | 15:33 |
| ypwong | you're welcome | 15:35 |
| mdeslaur | infinity: could you please denew xchat-gnome-indicator? | 17:23 |
| mdeslaur | infinity: and promote it to main and demote xchat-indicator to universe? | 17:23 |
| ogra_ | *sniff* | 17:27 |
| mdeslaur | ogra_: heh, xchat is in universe, no sense in having the indicator in main :P | 17:27 |
| infinity | mdeslaur: Err, why should it be in main? | 17:28 |
| infinity | If xchat is in universe... | 17:28 |
| mdeslaur | infinity: xchat-gnome-indicator needs to be in main because xchat-gnome is in main | 17:28 |
| mdeslaur | the xchat-indicator package used to build two binary packages: xchat-gnome-indicator and xchat-indicator | 17:28 |
| infinity | Oh, derp. Kay. Do dependencies or seeds reflect this? | 17:28 |
| mdeslaur | but I split it because one now needs to be gtk3 | 17:28 |
| ogra_ | infinity, we support the castrated version now | 17:28 |
| infinity | I'll look in a second. | 17:29 |
| infinity | Updating my local seeds. | 17:29 |
| mdeslaur | ogra_: what's castrated about it? | 17:29 |
| ogra_ | only half the features | 17:29 |
| mdeslaur | such as? /me is truly curious | 17:30 |
| infinity | xchat is an abomination anyway. :P | 17:30 |
| infinity | People need to learn how to use terminals. | 17:30 |
| mdeslaur | lol | 17:30 |
| davmor2 | mdeslaur: no people list on the right, some commands don't work, some plugins don't work the list goes on but I can't remember them all | 17:46 |
| mdeslaur | oh, the people list on the right has been back for a few years | 17:46 |
| mdeslaur | it's just off by default, you need to click the option | 17:46 |
| mdeslaur | I wouldn't be able to use it without the people list :) | 17:47 |
| davmor2 | mdeslaur: xchat is the base for which xchat-gnome modifies why have the modification when you can have the real deal ;) | 17:50 |
| mdeslaur | hehe | 17:51 |
| infinity | davmor2: Because the real deal is hideous. | 17:51 |
| infinity | (I assume xchat-gnome is slightly less ugly?) | 17:51 |
| infinity | Otherwise, I really wouldn't see the point. | 17:51 |
| davmor2 | infinity: not really | 17:51 |
| davmor2 | infinity: it's mostly just simplified | 17:52 |
| infinity | So, still ugly as sin and doesn't match the design/UI guildelines of any DE since the dawn of time? :/ | 17:52 |
| mdeslaur | There was a reason I switched at some point, but I honestly can't remember what it was | 17:52 |
| infinity | One has to try really hard to make something look worse than CDE, I commend them for succeeding, at least. | 17:53 |
| * mdeslaur wonders if having used CDE makes him privileged, or just old. | 17:54 | |
| infinity | mdeslaur: Both. | 17:54 |
| infinity | mdeslaur: Well, or neither, I suppose, since it became freely available long after it was relevant, so some young kids saw it for funsies. | 17:54 |
| mdeslaur | heh | 17:55 |
| infinity | mdeslaur: But when I used it, it was cutting edge, and only shipped on hideously expensive workstations, as I assume is the case for you. | 17:55 |
| cyphermox | on Sun workstations for me at least :/ | 17:55 |
| infinity | HP workstations for me. | 17:55 |
| infinity | HP workstations that cost more than my parents' house. | 17:55 |
| infinity | 120k for a tiny little grey box with the density of a star. | 17:56 |
| mdeslaur | on Sun workstations, with the backspace key that prints ^? instead of doing anything useful | 17:56 |
| infinity | I still don't know what alloy HP was using for those heatsinks, but I'm partially convinced it was of alien origin. | 17:56 |
| cyphermox | infinity: if you could review upstart-watchdog next, since you're reviewing ugly stuff, I'd be very grateful ;) | 17:56 |
| cyphermox | mdeslaur: yeah, I had forgotten about that | 17:56 |
| cyphermox | I kept one sun keyboard from the office for nostalgia | 17:57 |
| * infinity still has a VT220 for nostalgia. | 17:58 | |
| infinity | Every once in a while, I dust it off, go "wow, was the monitor really that tiny, it seemed so huge!" and then resolve to never plug it in again. | 17:59 |
| infinity | upstart-watchdog - watchdog jobs to reboot when system or session jobs fail | 18:02 |
| infinity | cyphermox: ^-- Automatic Windows administration? | 18:02 |
| cyphermox | ahah, something like that :) | 18:03 |
| infinity | cyphermox: The description alone doesn't make me want to review this. :P | 18:03 |
| infinity | cyphermox: So, I have two questions. (A) why do we need this and, (B) why do we care, if we're transitioning away from upstart? | 18:04 |
| infinity | cyphermox: And (C) if this is a useful feature, why isn't it being proposed for upstart istself instead of a helper package? | 18:04 |
| cyphermox | it's for the phone, if upstart jobs get into a respawn loop, most are critical and the phone just won't be useful without them running | 18:05 |
| cyphermox | as for B) | 18:05 |
| cyphermox | it's temporary indeed, until we can use systemd, etc. | 18:05 |
| infinity | cyphermox: If a job is in a respawn loop, what makes us think rebooting will magically fix it? Won't we then just end up in a reboot loop? | 18:05 |
| cyphermox | and C) I don't know if you'd really necessarily want that on desktop, on the phone we have a bit more control and sight to make sure these respawning loops don't happen as often | 18:06 |
| cyphermox | infinity: it's a concern, yes. but on the phone it was decided it would be just fine in that case, if you do end up in a reboot loop, to call customer support to get help | 18:06 |
| infinity | cyphermox: In theory, yes, though it actually makes the job of support a lot harder, since diagnosing an endlessly rebooting device is Really Hard. | 18:07 |
| cyphermox | on the phone, you can get into recovery at least | 18:07 |
| infinity | cyphermox: "My phone app keeps crashing" is easier to debug on the fly than "my entire phone reboots every time it gets to the desktop". | 18:08 |
| cyphermox | phone apps aren't usually upstart jobs | 18:08 |
| infinity | Perhaps a moot point, though, since I don't see a whole lot of remote debugging being a thing on the phone. | 18:08 |
| cyphermox | we're looking at indicators, ofono and such right now | 18:08 |
| infinity | And phones in such a state (in a commercial context anyway) will just lead to returns or reflashes, not debugging. | 18:08 |
| cyphermox | yes, reflashing | 18:08 |
| cyphermox | or returns, indeed | 18:09 |
| cyphermox | rsalveti: want to chime in ^ ? | 18:09 |
| infinity | cyphermox: Not going to pressure anyone to provide this for a 1.0 shipping image or anything, but if we're going to go down the "we can't figure out how to recover cleanly, so just reboot" road, you probably also want to count the reboots and trap on boot "if count-in-last-hour >= 3" or something, and put up a "your phone might be buggered, please contact support or visit this web page for recovery options" dialog. | 18:10 |
| cyphermox | infinity: the premise is that these job failures shouldn't happen in the first place, and at least trying to recover automatically by rebooting in case, say, ofono died, is more likely to lead to a phone that works again | 18:11 |
| cyphermox | infinity: we discussed that approach | 18:11 |
| cyphermox | decided people already were expected to call support if their phone was stuck rebooting all the time | 18:11 |
| infinity | It's a nice theory. People need to be hand-held a bit, I find. | 18:12 |
| cyphermox | ie. that it was obvious enough when you keep seeing the boot animation | 18:12 |
| cyphermox | I don't necessarily disagree | 18:12 |
| infinity | I have a lot of non-technical friends who, when systems get in such a state, just decide that's the New World Order, until a computery friend comes along, looks at how they use their phone, laptop, etc, and goes "DUDE, WTF." | 18:12 |
| cyphermox | I'm just following what we discussed in our sprint planning | 18:12 |
| cyphermox | haha, yeah | 18:12 |
| infinity | "Yes, mom, it's perfectly normal for the new Android to reboot 7 times after a phone call, you made the right decision to not return it to the store for service, CAN YOU HEAR MY SARCASM?" | 18:15 |
| * rsalveti waves | 18:15 | |
| cyphermox | ahah | 18:16 |
| rsalveti | infinity: yeah, we decided initially to just make it to reboot | 18:17 |
| rsalveti | later one we need to talk with design to see if we want a different approach | 18:17 |
| rsalveti | like getting into recovery or something | 18:17 |
| infinity | Recovery is scary too. But something that catches a reboot loop and offers direction would be pleasant. | 18:17 |
| rsalveti | reboot, hope for the best, and let the user to call support if the phone is rebooting non-stop | 18:18 |
| cyphermox | infinity: or, the fact that the phone beeps constantly, and changes the wallpaper by itself when it's charging after 5 minutes... only if you set your language to French (Canada) in Android 5.0? :D | 18:18 |
| rsalveti | infinity: right, hard to find out the right one there, you don't want the phone to appear as working somehow for the user | 18:18 |
| rsalveti | so that's why recovery is used by android | 18:18 |
| cyphermox | rsalveti: nothing makes it impossible to do that though | 18:18 |
| rsalveti | right | 18:18 |
| infinity | cyphermox: That's a feature. | 18:19 |
| cyphermox | rsalveti: I can just add some logic to the pacakge for a next release to get to recovery | 18:19 |
| cyphermox | infinity: figured you would say that | 18:19 |
| infinity | cyphermox: PS: Stop being French Canadian. | 18:19 |
| rsalveti | cyphermox: right, better to discuss that though, as we decided to not do that initially | 18:19 |
| cyphermox | at least now I don't need to try to say "1$s" in place of "Ok Google" :) | 18:19 |
| cyphermox | rsalveti: yes | 18:19 |
| rsalveti | as we need to show up something on recovery | 18:19 |
| infinity | cyphermox: Hahahhaa. Seriously? | 18:19 |
| rsalveti | which then makes us talking with design, and that will take forever | 18:20 |
| cyphermox | rsalveti: I'm just saying, we can come up with an updated way to handle this | 18:20 |
| rsalveti | sure | 18:20 |
| cyphermox | at least for now there is something | 18:20 |
| cyphermox | infinity: yes, seriously. I did try it, doesn't work ;) | 18:20 |
| infinity | cyphermox: Pronounced "one dollar ess", or perhaps "one string"? | 18:22 |
| * mdeslaur is glad infinity is back from vacation | 18:22 | |
| cyphermox | hmm, would need more testing. | 18:22 |
| infinity | Anyhow, the package looks like it should do what it claims it does. | 18:22 |
| infinity | I'm pretty not okay with the approach, but I'll handwave for now and hope people come up with something less evil. | 18:23 |
| cyphermox | handwave duly recorded | 18:23 |
| * ogra_ notices an urge to join one of the phone teams in infinity's voice | 18:24 | |
| * infinity panics. | 18:24 | |
| ogra_ | lol | 18:24 |
| cyphermox | rsalveti: let's move this conversation to #ubuntu-touch and think about it some more | 18:24 |
| * mdeslaur watches upstart-watchdog restart infinity | 18:24 | |
| xnox | mdeslaur: infinity: i'm half and half. Half using x-chat, and the other half using hexchat (fork of original xchat to keep it "maintained") | 20:14 |
| mdeslaur | xnox: why are you still using xchat? hexchat is pretty much the same, no? | 20:14 |
| xnox | cyphermox: all phone apps are upstart jobs at the moment (user session upstart, not system one, but still ;-) ) | 20:16 |
| cyphermox | xnox: but I don't think apps in the standard sense really so much use respawn anyway | 20:17 |
| cyphermox | indicators I agree with. some random browser app or game, not so much | 20:17 |
| xnox | mdeslaur: there is no hexchat-indicator yet. | 20:19 |
| xnox | mdeslaur: i'm meant to port it or find a port. | 20:19 |
| xnox | cyphermox: indicators are running as upstart jobs.... in a user session upstart, not system one. | 20:20 |
| mdeslaur | xnox: hrm, what if you just symlink the xchat-indicator plugin into the hexchat plugin directory? | 20:20 |
| cyphermox | xnox: yes, I know :) | 20:20 |
| xnox | cyphermox: so upstart-watchdog reboots from unpriviledged user? and security team let it through? it's not like mdeslaur is right here, reading this. | 20:20 |
| xnox | mdeslaur: looking at the code they renamed s/^X/HEX/ all symbols so I daubt it, but maybe it works.... | 20:21 |
| mdeslaur | xnox: oh, darn, that sucks | 20:21 |
| * xnox fetches to read it. | 20:21 | |
| mdeslaur | I didn't know they did that for the plugin api | 20:21 |
| xnox | mdeslaur: i'll double check to confirm. | 20:22 |
| mdeslaur | it's possible | 20:22 |
| xnox | cyphermox: actually reading the whole black magic it seems ok. However do check that you don't have intentional things: emitting RESULT="failed" PROCESS="respawn" and rather be left alone instead of rebooting. | 20:24 |
| xnox | cyphermox: e.g. for example upstart-plymouth-bridge i believe just does that - respawning until giving up, if there is no plymouth daemon running. And that's "normal". | 20:24 |
| === Guest36844 is now known as rcj | ||
| === rcj is now known as Guest84698 | ||
| === Guest84698 is now known as rcj_ghost | ||
| DalekSec | mdeslaur: https://code.launchpad.net/hexchat-indicator | 20:28 |
| xnox | mdeslaur: may i work on merging xchat-gnome-indicator & xchat-indicator to be (a) single source code base (b) be able to build for both simultaniously (c) possibly add hexchat-indicator? | 20:30 |
| mdeslaur | xnox: well, no, I just split it | 20:31 |
| cyphermox | hahaha | 20:31 |
| mdeslaur | xnox: so that gtk2 can go away to universe | 20:31 |
| mdeslaur | (evetually) | 20:31 |
| mdeslaur | xnox: you can add it to the xchat-indicator package though | 20:31 |
| xnox | mdeslaur: haha. qt5 & qt4 are not ported from gtk2 to gtk3 yet. | 20:31 |
| * xnox double checks | 20:32 | |
| mdeslaur | qt? | 20:32 |
| mdeslaur | what, for theming? | 20:32 |
| mdeslaur | why is qt using gtk? | 20:32 |
| xnox | $ reverse-depends libgtk2.0-0 | grep qt | 20:33 |
| xnox | * appmenu-qt5 | 20:33 |
| xnox | * gtk2-engines-qtcurve | 20:33 |
| xnox | * libqt5gui5 | 20:33 |
| xnox | * libqt5gui5-gles [amd64 i386] | 20:33 |
| xnox | funny how gles is compiled with gtk support for themeing. | 20:33 |
| xnox | making gles not be compiled against gtk2 and not sure how appmenu is in there | 20:33 |
| xnox | but if gles is compiled without gtk theming it could make gtk2 be dropped from phone images atleast. | 20:34 |
| mdeslaur | well, anyway, having the same codebase for gtk2 and gtk3 in the indicator and building twice was painful | 20:34 |
| mdeslaur | but I think adding hexchat support to the xchat-indicator package would make sense | 20:34 |
| xnox | mdeslaur: yeah, true. i'm not sure what to base hexchat on then. | 20:34 |
| mdeslaur | and is likely to be trivial | 20:35 |
| xnox | it's gtk, so i'll keep it there. | 20:35 |
| xnox | mdeslaur: reading the net-diff between xchat-gnome-indicator and xchat-indicator - i'm pretty sure the same patches are valid for gtk2... | 20:36 |
| mdeslaur | nope, I tried | 20:36 |
| mdeslaur | wait a sec, I'll tell you which ones | 20:36 |
| mdeslaur | gdk_x11_window_get_xid for one | 20:38 |
| * ScottK notes the channel and wonders if maybe we've wondered a tad off topic. | 20:39 | |
| * mdeslaur moves to #ubuntu-devel | 20:39 | |
| xnox | mdeslaur moves... the conversation or ScottK ?! =)))))))) *giggle* | 20:40 |
| ScottK | Pondering the imminent demise of keys < 2048 in Debian, should we do something similar? | 21:20 |
| xnox | ScottK: we ain't even got a web of trust among all devs really... =) | 21:32 |
| ScottK | No, we all trust in Launchpad. | 21:32 |
| xnox | ScottK: but yeah, running a script to get all key ids and get some stats on key sizes would be useful to at least assess the situation and whether it's better or worse than debian etc. | 21:33 |
| * xnox hopes we do not have recursive team memberships.... | 21:56 | |
| stgraber | xnox: we've got 304 keys currently with upload rights | 21:57 |
| stgraber | (that's recursive ~ubuntu-dev + the PPU people) | 21:57 |
| stgraber | I just need to create a GPG keyring now and load them all in there, then check for < 2048rsa | 21:58 |
| xnox | stgraber: you are faster with launchpad api than I am =) my script is still running.... | 21:59 |
| stgraber | xnox: downloading the keys from keyserver.ubuntu.com now | 22:00 |
| stgraber | xnox: it's basically just a loop over lp.people['ubuntu-dev'].participants, for each grabbing all the keys from people.gpg_keys, then doing the same for all the people with PPU upload rights (I've got a report with the list of usernames), stuffing all that into a set | 22:01 |
| stgraber | got a third of the keyring downloaded :) | 22:02 |
| infinity | stgraber: You'll find people like me who still have their old key in LP. I intend to remove it after keyring-maint finally swaps my new key into the Debian keyring. | 22:03 |
| xnox | stgraber: ah, i've missed participants. i was doing recursive iteration over getMembersByStatus and calling oneself over if it's a team - http://paste.ubuntu.com/9256636/ | 22:03 |
| ScottK | So far, AFAIK, we don't even have a policy of retiring the older keys, so we've got to start somewhere. | 22:04 |
| infinity | ScottK: Well, once we know the current situation, we can talk policy. | 22:05 |
| ScottK | Sure. | 22:05 |
| infinity | ScottK: Having the [ACCEPT] email warn about short signing keys would be a good first step. Then we could eventually move to just REJECTing uploads signed by short keys, even if they're valid and attached to the user. | 22:05 |
| ScottK | That'd be a start. | 22:06 |
| infinity | Which also means people don't need to remove their old keys, we just stop trusting them. | 22:06 |
| ScottK | Yeah | 22:06 |
| stgraber | there you go: http://paste.ubuntu.com/9256745/ | 22:09 |
| xnox | stgraber: what about subkeys? launchpad accepts uploads singed by signing subkeys | 22:09 |
| xnox | i think we are better than debian in terms of % of <2k keys. | 22:11 |
| stgraber | xnox: give me a patch against http://paste.ubuntu.com/9256773/ and I'll happily run it :) | 22:11 |
| infinity | stgraber: So, if we ignore 2048 as borderline, looks like we're about 50/50 good/bad. | 22:12 |
| stgraber | infinity: yup | 22:12 |
| infinity | stgraber: Except I bet that also counts both keys for people who have two? | 22:12 |
| stgraber | it does | 22:12 |
| stgraber | and it should | 22:12 |
| stgraber | since both are valid for uploads to the archive | 22:12 |
| infinity | stgraber: Well, no. It shouldn't, from the POV of "how far do we have to go to fix it". | 22:13 |
| infinity | stgraber: Cause if we stopped trusting 1024 today, people like Colin and I could still upload fine, even thought we have 1024 keys in your analysis. | 22:13 |
| infinity | stgraber: So, I want to know how many *users* couldn't upload in that case, not how many *keys*. | 22:13 |
| stgraber | yeah, I'd have to make an actual script for that rather than just type stuff in lp-shell :) | 22:16 |
| infinity | Since we have no actual web of trust (for better or worse), we are in a position where we could move quickly if we did decide on a policy, at least. | 22:17 |
| infinity | Cause an individual can generate and upload a key in a matter of minutes, it needs no other action. | 22:17 |
| xnox | stgraber: can you send me the keyring itself please? | 22:17 |
| stgraber | xnox: sure, one sec | 22:18 |
| xnox | stgraber: tah. | 22:18 |
| stgraber | xnox: https://dl.stgraber.org/ubuntu-keyring.asc | 22:19 |
| xnox | stgraber: tah. | 22:20 |
| infinity | Oh, keyring-maint *did* replace my key in Debian, I just foolishly thought I'd get an email about it when they did. | 22:21 |
| infinity | I guess that email would have come in the form of a reject from DAK on my next upload. :P | 22:21 |
| ScottK | No need to provide the information before you need it. | 22:22 |
| ScottK | This way you won't forget. | 22:22 |
| xnox | rough stats of public & subkey algos and sizes http://paste.ubuntu.com/9256897/ | 22:25 |
| infinity | wgrant: Are the ACCEPT message from soyuz a straight CC to -changes and the uploader, or are they individually crafted? | 22:25 |
| stgraber | almost done writing a clever script | 22:25 |
| infinity | wgrant: If we decide to start deprecating short keys, I'd like to tack a warning on the ACCEPT sent to the user, but no need to publically shame them on -changes | 22:25 |
| xnox | this doesn't check if the subkey is encrypt only... e.g. like elg* | 22:26 |
| stgraber | it's gonna be very slow though but very accurate (iterates through the archive privileges for all the archives) | 22:26 |
| wgrant | infinity: I believe they're separate, but we should really just email people directly. | 22:26 |
| wgrant | Not much point having a warning about it. | 22:26 |
| xnox | stgraber: infinity: so we have like 11 rsa keys <2k, the rest of small keys are DSA | 22:27 |
| infinity | wgrant: Well, an email to devel-announce obviously, with the policy. And individual nag mails. But I like the idea of warning "we accepted, but..." | 22:27 |
| infinity | wgrant: Maybe there's little point. | 22:27 |
| xnox | imho killing DSA keys should be easy / first target. | 22:27 |
| ScottK | Kill them all. | 22:27 |
| xnox | =) | 22:27 |
| xnox | infinity: no need to hack soyuz.... mail announce ubuntu-devel-announce. Do another followup, rerun/check how effective that was. Mass individual email (launchpad email if present, key's emails otherwise) | 22:29 |
| xnox | and then purge. | 22:29 |
| infinity | ScottK: I think this should probably be a joint TB/AA decision. Want to start a cross-posted discussion and we'll draft something to send to -announce when we all agree? | 22:29 |
| xnox | infinity: it's not like we lock people out like debian, one can simply generate new key, login and add it. | 22:29 |
| ScottK | Sure. | 22:29 |
| infinity | xnox: No purging required, we can just reject if signed by a key type we don't like, even if the key is known to us. | 22:29 |
| xnox | infinity: bigger question is - what about everyone? for PPA access/uploads? | 22:29 |
| xnox | infinity: right, ok. | 22:30 |
| * stgraber sshes to snakefruit so he can abuse LP much faster than from home | 22:30 | |
| xnox | infinity: yeah force removing keys from profiles sounds bad. | 22:30 |
| infinity | And that's a fair point, TB/AA can't really make policy decisions for PPAs, but lp-dev can. | 22:30 |
| infinity | wgrant: ^ | 22:30 |
| wgrant | "can't really" -> "can't at all" :) | 22:31 |
| wgrant | I'd need to collect more data there. | 22:32 |
| infinity | Pretty sure we can have different acceptance criteria in the short term, if we want to move quickly for the distro but feel it's too disruptive for PPAs. | 22:32 |
| wgrant | And we also need to devise a solution for PPA signing keys themselves. | 22:32 |
| wgrant | Remember that copies are a thing, though. | 22:32 |
| infinity | The PPA signing key thing definitely needs to be solved, yes. | 22:32 |
| xnox | wgrant: what's the algo/size for ppa singing keys? have they been rotated - ever? | 22:32 |
| stgraber | xnox: 1024R for old PPAs | 22:32 |
| xnox | horum. | 22:33 |
| wgrant | There's no way to rotate them, which is the problem. | 22:33 |
| wgrant | Ubuntu does it with a package that hacks apt's keyrings. | 22:33 |
| xnox | yeah maybe we should practice what we are going to preach =) | 22:33 |
| infinity | wgrant: Copies imply (however incorrectly) that you've validated the thing you're copying and you're now using your direct LP creds to do the copy to the target, the original signer is irrelevant. | 22:33 |
| stgraber | and indeed copies are a good point, I don't suppose LP keeps a reference to the key which was used for the initial upload so we can reject the sync? | 22:33 |
| wgrant | stgraber: It does. | 22:33 |
| wgrant | But some things (eg. recipes) aren't signed, so it's not quite trivial. | 22:33 |
| xnox | .... which brings us to ssh key sizes as well. | 22:34 |
| xnox | and the ssh-blacklist =))))) | 22:34 |
| stgraber | let's try to fix one thing at once :) | 22:35 |
| xnox | stgraber: nah, we want to break everything at the same time. | 22:36 |
| infinity | How do SSH keysizes matter at all? | 22:36 |
| stgraber | turns out iterating through getAllPermissions and then grabbing all members of the team (if it's a team), not a very fast operation :) | 22:36 |
| stgraber | infinity: commit to bzr branches which use recipes | 22:37 |
| infinity | People doing sftp uploads are still GPG-signing their packages, so I don't actually care if their SSH login is insecure. | 22:37 |
| infinity | stgraber: Oh, recipes. Kay, that's back to the PPA thing, though. | 22:37 |
| stgraber | yeah | 22:37 |
| infinity | Let's stick with distro policy first. | 22:37 |
| xnox | launchpad's ssl cert chain is all 2k RSA, so that's good. | 22:37 |
| wgrant | And it should be SHA-256 all the way nowadays. | 22:38 |
| stgraber | same for SSO, so yeah, SSL seems fine | 22:38 |
| wgrant | I whined enough. | 22:38 |
| stgraber | :) | 22:38 |
| infinity | Well, this is good, though. SSL being fine is a prereq for trusting the key replacement process. :P | 22:39 |
| xnox | wgrant: all but the top level CA - it has sha256 fingerprint, but the selfsig is SHA1 it seems. | 22:39 |
| infinity | I still wish we had a Debian-style WoT requirement for our signing keys, but whatever. | 22:39 |
| infinity | That ship sailed long ago. | 22:39 |
| xnox | wgrant: all other certs in the chain are sha256. | 22:39 |
| stgraber | wow, that script is really incredibly slow... looks like I'll need to add some logic if I don't want it to take an hour and end up upsetting wgrant | 22:40 |
| infinity | ScottK: Anyhow. Thanks for bringing it up. I thought about it earlier this year, but didn't want to bring it up while I was a hypocrite still uploading to both Debian and Ubuntu with a 1024D key from 2002. | 22:42 |
| tumbleweed | :) | 22:43 |
| wgrant | xnox: The root cert's self-sig doesn't matter, since it's only trusted by the fingerprint stored in the browser's CA DB. | 22:43 |
| xnox | wgrant: i see. | 22:43 |
| stgraber | yay, the script seems to work so far: | 22:50 |
| stgraber | stgraber@snakefruit:~$ ./ubuntu-gpg-stats.py | 22:50 |
| stgraber | Ubuntu has a total of 207 uploaders. | 22:50 |
| stgraber | Ubuntu has a total of 314 GPG keys with upload privileges tied to them. | 22:50 |
| cjwatson | xnox: The ssh blacklist is dead, along with the code to deal with it; if you want me to resurrect it and carry on maintaining it you'd better have an exceptionally compelling argument :-) | 22:52 |
| cjwatson | Because maintaining that openssh patch sucked. | 22:52 |
| === rcj_ghost is now known as rcj | ||
| xnox | cjwatson: i know. I like the openssl-blacklist approach where it's stand-alone set of datapoints. | 22:53 |
| xnox | cjwatson: i've blogged - it appears a few of the openssh/openssl bad keys leaked into openpgp web of trust, thanks to monkeysphere conversion. I'm planning to find and revoke those. | 22:54 |
| xnox | cjwatson: but i presume launchpad did database clean-up removed dupes?! | 22:54 |
| xnox | cjwatson: well probably nothing to answer publically here. | 22:55 |
| cjwatson | Pretty sure that was cleaned up centrally at the time, though, well, it was six years ago and memory is fuzzy. | 22:56 |
| cjwatson | I remember us looking at a query to find duplicates though. | 22:56 |
| wgrant | I remember something being done about that, yes. | 22:56 |
| wgrant | Not that I was an insider at the time. | 22:56 |
| cjwatson | Haha it looks like I ran the query indeed | 22:58 |
| cjwatson | 18:44 <@elmo> (Do I want to know how you guys are backdooring LP? :-P) | 22:58 |
| cjwatson | 18:44 <@cjwatson> the dump on mawson | 22:58 |
| cjwatson | 18:44 <@cjwatson> it's not entirely up to date, but | 22:58 |
| cjwatson | 18:45 <@cjwatson> I didn't *really* want to explain to somebody what I wanted to do on production | 22:58 |
| xnox | LOLZ | 22:59 |
| wgrant | Heh | 22:59 |
| xnox | *really* yeah *really* =) | 22:59 |
| cjwatson | Though I think my SQL at the time sucked even more than it does now and I just pulled the list of all fingerprints and postprocessed or something stupid like that. Anyway, don't really want to go spelunking the logs of #argh at this remove :-) | 23:00 |
| cjwatson | (Yes, that was the internal channel name) | 23:01 |
| cjwatson | 2008-05-13.log:16:21 <@elmo> LP keys deleted | 23:02 |
| cjwatson | Guess that covered that | 23:02 |
| ScottK | Mail sent. | 23:08 |
| stgraber | xnox, infinity: http://paste.ubuntu.com/9257987/ will get you one keyring per user and a global "ubuntu-archive" keyring. Shouldn't be too difficult to then look for people with multiple keys and see if one of those match the future criteria. | 23:47 |
| xnox | stgraber: cool. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!