19:00:57 #startmeeting storyboard 19:00:59 Meeting started Wed Oct 31 19:00:57 2018 UTC and is due to finish in 60 minutes. The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:59 hey howdy! 19:01:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:02 The meeting name has been set to 'storyboard' 19:01:08 Hello! 19:02:06 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard#Agenda_for_next_meeting Agenda 19:02:37 #topic Migration Updates 19:02:44 any updates this week diablo_rojo? 19:03:48 * fungi hopes we're not keeping SotK from evening hallowe'en festivities 19:04:08 Sadly not, just that I still haven't had time to dig into the LP API to figure why things are being cut short of the full migration 19:04:15 Yeah we can make this quick 19:04:36 full neutron migration, right 19:04:44 Right 19:04:59 On the attachment spec I think it would be helpful for storyboard to describe the requirements it feels it has for this feature. Then we can build around that rather than going with whatever infra could do today. THis helps inform both directions of the needs and limitations I think. 19:05:27 * fungi thinks clarkb is jumping ahead on the agenda ;) 19:05:34 * diablo_rojo thinks so too 19:05:44 sorry 19:05:54 Attachments are just so exciting :0 19:05:54 (that was my update) 19:06:25 they are! 19:06:54 diablo_rojo: no worries, I've also not had much time this week 19:07:06 #topic Berlin 19:07:18 (I now see the topic was specifically migration updates) 19:07:23 WRT the neutron migration, I am kind of prioritizing the attachment spec and moving that forward higher. Hence the lack of progress. 19:07:28 clarkb, lol 19:07:36 yeah that makes sense to me 19:08:03 Nothing new on the Berlin topic, just wanted to make sure those watching knew about it. 19:09:37 #topic Story Attachments 19:09:55 I could send something to the ML telling people to bring last concerns to the Berlin forum session? 19:10:07 Just a thought 19:10:14 diablo_rojo: ++ and remind them that storyboard will be there is probably worthwhile 19:10:24 diablo_rojo: yep that sounds worthwhile 19:10:31 * diablo_rojo adds that as a todo for today 19:11:03 Anywho, attachment things now :) 19:11:04 so on the attachments spec, i feel like the actual requirements are fairly nominal/flexible, but a lot of that has to do with how we design the feature 19:11:14 storage requirements i mean 19:11:48 ya I'm sure we can make something work. But I think it would be valuable to undersatnd how storyboard would like to see it work 19:11:58 Then see if the hosting can accomodate that (rather than the other way around) 19:12:03 i'm also curious as to whether the comments i posted make sense, with regards to a simpler way to go about this security-wise 19:12:53 fungi, it mostly made sense, I think I was failing to see how it was different than the undiscoverable URIs? 19:12:58 if an attachment is only reachable by knowing its url which includes a uuid someone would have to guess or otherwise be provided, is that sufficiently secure? 19:13:37 I would guess so? but I certainly am no security expert 19:13:38 other parts of the spec described temporary urls and/or proxying all the content requests through storyboard 19:13:38 I think the part I was misunderstanding from your idea was that the URL is determined at upload time and recorded in storyboard, rather than being generated on demand 19:13:56 I think this way sounds much easier to implement 19:14:08 but I don't really feel entirely qualified to comment on its security 19:14:24 I don't see anything immediately wrong 19:14:34 One of the differences is that if there is a magic open URI, that can be pasted to e.g. IRC. Conversely, if control is managed by storyboard directly, pasting the URI doesn't disclose anything. Personally, I think having a separate storage system (with guessable UUIDs) is probably sufficiently secure for task tracking, but others may be more concerned. 19:15:05 The two big things seem to be controllable URIs and indexable content 19:15:23 yeah, my take is that if someone can leak the persistent url to the attachment, then they can just as easily leak the contents of the attachment or other aspects of the private story anyway 19:15:24 What is the benefit of indexable content? 19:15:42 persia: you can store adsvertisements or similar that show up in google seraches 19:15:44 fungi: Absolutely. 19:16:09 clarkb: I consider that a detriment, but I can see the potential for abuse. 19:16:09 this is the sort of spamming we've seen on our wiki 19:16:37 yeah, i think what clarkb means is we don't want them indexable. i mentioned some possible solutions to that as well 19:16:40 Has anyone asked #launchpad how they deal with the potential for spam? 19:17:15 persia, I have not 19:17:18 doesn't prevent someone from posting the url to an attachment somewhere else where it can then be indexed by a search engine i guess, but these days that's a less attractive prospect 19:17:20 but that would be useful information 19:17:47 basically if they already have somewhere unpoliced to post the url, then they'd just post the raw content there instead 19:17:58 My vague memory is that they have a policy and a means to delete things that seems to work. Dunno about volume of LP-hosted projects vs. OSF-hosted projects. 19:18:04 that's what we saw happening with our wiki, fwiw 19:19:00 fungi, posting advertisemnets or logs of things? 19:19:16 i do agree with clarkb that it's something we should keep an eye out for, and don't think it should really factor too much into the design 19:19:41 diablo_rojo: these days it's mostly people posting urls to scams or phone numbers for the same 19:19:58 Got it. 19:20:12 so that when you google "miscrosoft office support" you get friendly results for a phone number to call where they'll take your credit card info 19:20:24 fungi: from the design side if say swift publicly served content doesn't allow you to not index (or alternatively index at all) that is something that should factor in? I agree ti shouldn't be the main consideration, just another thing to check when considering options 19:21:00 yes, if the object store conveniently provides a public index to all content you serve from it, that would be something to discount it 19:21:26 i don't think swift forces a public index of your objects, for precisely this reason 19:21:35 Something we don't want. 19:22:47 basically, under my suggested design, we would want storyboard to privately maintain its index of (persistent public) object urls, and would not want the object store to serve an index of those 19:23:11 fungi: makes sense to me 19:23:21 we also would want to be sure said urls couldn't be enumerated in any achievable amount of time 19:23:34 by someone who lacks access to that index 19:24:18 * SotK thinks that this sounds like the best solution of the ones that have been suggested 19:24:37 Indeed 19:24:44 anyway, i didn't want to monopolize the discussion, just want to be sure we don't go off overengineering complex solutions where simpler ones are possible 19:25:04 ++ 19:25:31 Lost connection on laptop. But I'll go back through meeting logs and get the spec updated with this approach. 19:25:53 thanks diablo_rojo_phon! and i hope your laptop didn't have too much candu 19:25:56 candy 19:25:58 makes sense, I don't really see any worthwhile benefit to the more complicated suggestions I noted now 19:26:09 I had most comments addressed aside from this section so I should have it up today ish. 19:26:23 nice, thanks :) 19:26:44 my old life as a security wonk mostly involved reminding people that complex security solutions are really just increased opportunities for vulnerabilities 19:27:04 Maintenance is in my apartment and flipped the breakers so I haz no internets. 19:27:52 I think that basically covers attachments then 19:27:58 #topic In Progress Work 19:28:00 Cool :) 19:28:02 and you're sure these aren't neighborhood hooligans disguised as maintenance workers? 19:28:37 fungi: pretty sure since he's fixed a bunch of other things in the apartment previously 19:28:52 I have two patches that could use reviews. 19:28:54 It's a long con then? 19:28:56 offer candy anyway 19:29:33 could be a really good costume 19:29:39 High level of dedication just to flip my breakers. 19:29:44 * SotK failed to get anywhere with his backlog of reviews to do, I'll attempt to get to them this week 19:29:55 * diablo_rojo_phon doesn't have any candy in the apartment 19:30:00 i only managed to review the attachments spec, fwiw 19:30:11 diablo_rojo_phon: shots then? 19:30:20 Thanks SotK :) We are all juggling a lot of stuff so we understand 19:30:47 fungi: could do that, there's no shortage of alcohol here lol 19:30:52 when i lived in raleigh, there was a townhouse of russians across the street who always set up a bar in their driveway and served vodka shots to the parents taking their kids around 19:31:06 it was pretty awesome 19:31:21 That is excellent. 19:31:40 SotK: I don't think I got around to reviewing your patch either so I guess it's only fair lol 19:31:56 ha, that's a great idea 19:32:06 I don't think I have enough alcohol around to do it though 19:32:12 diablo_rojo_phon: no worries :) 19:32:45 I think folk have mostly learnt the workaround for the bug that patch fixes at this point 19:32:51 * diablo_rojo_phon thought about sharing a photo and decided that proof doesn't need to exist on the internet. 19:32:53 or at least, I've not noticed anyone complain recently 19:33:10 Still nice to get it fixed SotK :) 19:33:16 indeed 19:35:41 Was someone investigating what happened with fatema's patch? 19:35:59 I was going to but also didn't get around to that 19:36:49 What say we end early to do some of these things? 19:36:59 Unless someone else has something to talk about? 19:37:01 sounds good to me 19:37:05 I don't have anything else 19:37:16 i'll review some storyboard changes 19:37:17 Oh! clarkb is there gonna be an infra dinner at the summit? 19:37:26 fungi: much appreciated! 19:39:46 diablo_rojo_phon: I haven't put together one 19:40:21 I guess I can take a look. Mostly its a huge pain to figure out reservations for a large group and half the time they want a deposit 19:40:37 Denver is easy because beer garden and nice weather. Berlin probably has the beer gardens but not the nice weather 19:41:15 berlin doesn't seem to have actively staffed biergartens in november 19:41:35 you need a bierstube instead, and seating will be more complicated 19:41:52 We can probably do an informal thing? I expect a smaller but also differentish group (frickler and ajaeger but no paul or david or robyn etc) 19:42:18 I'll send out an email trying to schedule an informal thing with the expectation that different tables/locations may happen 19:42:20 I think that is easiest 19:42:26 we can say "everybody meet at $venue and we can try to get tables nearish to each other" 19:42:32 ++ 19:42:42 but not actually organize anything 19:43:36 That works. 19:47:07 ok, lets end the meeting 19:47:15 thanks for coming folks :) 19:47:21 #endmeeting