libravatar-fans team mailing list archive

[Lars Kruse <lists@xxxxxxxxxxxxx>]

Hello,

we finished today's bi-weekly IRC meeting.

You can find a short summary of the discussion is in the wiki:
 https://wiki.libravatar.org/shutdown-coordination/?updated#index2h2
You find the full log attached.

We postponed a discussion about the "fallback to gravatar" feature to the
next meeting.

The next IRC meeting will happen on the 25th of November at 19:00 UTC in
#libravatar at freenode.

Cheers,
Lars

20:17 <sumpfralle4> What happened in the last weeks?
20:18 <tleguern> I got to ran a few tests on both the current libravatar and the ofalk's.
20:18 <sumpfralle4> sounds great!
20:19 <tleguern> I am not knowledgable in the JPEG format so I mostly tried stuff with PNG input.
20:20 <sumpfralle4> That should be sufficient for most parts of the service, I guess.
20:20 --> clime1 (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) hat den Channel #libravatar betreten
20:21 <sumpfralle4> Did you publish your tests somewhere?
20:21 <sumpfralle4> (the URL you provided last time did not receive updates, I think)
20:21 <tleguern> Not yet but I can give a summary
20:22 <tleguern> The most important point: the new implementation leaks user image to any logged in user.
20:22 <tleguern> The images are accessible at this URL: https://avatars.linux-kernel.at/accounts/raw_image/12
20:22 <tleguern> Changing the number gives you someone elses images.
20:22 <tleguern> Not necessarily a big security thing, but still.
20:22 <sumpfralle4> "user image" -> the original uploaded image
20:23 <nipos> Is that really a bug?These photos are uploaded especially for public use
20:23 <sumpfralle4> yes, ofalk will appreciate that feedback
20:23 <tleguern> sumpfralle4: the cropped image, not the original one.
20:23 <nipos> And the old implementation supported direct access to the user image,too but the id was a hash there
20:24 <tleguern> nipos: they should at list not be accessible through this URL
20:24 <sumpfralle4> It feels like it should not be public (i.e. slightly outside of the scope of "providing small pictures for each user").
20:25 <tleguern> Otherwise both implementations rewrite the PNG file, removing metadata and optional chunks and also rearanging the pixels.
20:26 <sumpfralle4> great - so you had a good look at the image processing details - nice!
20:27 <sumpfralle4> Other things that happened in the last weeks?
20:28 <nipos> For my designing stuff unluckily no.I had to repair two laptops and I'm lacking of time :(
20:28 <sumpfralle4> hardware is always a quite effective time sink :)
20:28 <clime1> i've setup the auto-deploy hook on libravatar-stg.fedorainfracloud.org
20:29 <sumpfralle4> So it is connected to the repository of the ansible recipe?
20:29 --> clime (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxx) hat den Channel #libravatar betreten
20:29 <clime> hey, got disconnected
20:30 <clime> not sure if you have read my messages?
20:30 <sumpfralle4> yes :)
20:30 <sumpfralle4> and I asked: So it is connected to the repository of the ansible recipe?
20:30 <clime> alright, it's connected to the linu.kernel.at ivatar repo
20:30 <-- clime1 (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) hat den IRC verlassen (Read error: Connection reset by peer)
20:31 <clime> when push happens there, an event is sent to the server (via webhooks)
20:31 <sumpfralle4> So we are ready to operate without human intervention :)
20:31 <clime> right
20:31 <sumpfralle4> Good!
20:32 <sumpfralle4> ofalk reported (via mailinglist), that he managed to import the original dataset, but did not test the process, yet.
20:32 <sumpfralle4> That should be enough for the last weeks, or?
20:33 <tleguern> On the login page I am greeted with “Benutzername”. Is there a translation problem happenning ? :P
20:33 <clime> cool
20:33 <nipos> Great so the biggest question (data migration) is finally solved :D
20:34 <sumpfralle4> I would call it "close to being finished" :)
20:34 <nipos> What's wrong with the translation Benutzername for username?
20:34 <tleguern> clime: it is not possible to register yet on the site. Is it expected ?
20:34 <tleguern> Well, my setup is in English, not German.
20:34 <clime> no, it's not
20:35 <tleguern> clime: This is my error message:Sending a message to tleguern@xxxxxxxxxxx from accounts@xxxxxxxxxxxxxxxxxx Mailgun API response 401: UNAUTHORIZED Forbidden
20:35 <nipos> That's weird.I use the translation variables in my template files but I don't know where the real translation strings are located
20:35 <clime> tleguern: yup, ok i need to get the mailgun api/auth keys probably from ofalk
20:35 <tleguern> nipos: Every thing is in English but this work.
20:36 <tleguern> word, sorry
20:36 <clime> it's trying to use mailgun without having them.
20:36 <clime> tleguern: i was able to create new user still though
20:36 <clime> login->create new user worked for me
20:37 <tleguern> Yes, I got the error at the “Add a new email address” form.
20:37 <clime> right
20:37 <sumpfralle4> btw: where do we currently file issues?
20:37 <tleguern> Sorry, I was not clear.
20:37 <nipos> <label for="id_username">{% trans 'Username' %}:</label> Looks right to me.
20:37 <clime> so i need to ask ofalk if we should use mailgun for sending emails and then get the auth keys
20:38 <nipos> (For the translation problem)
20:38 <clime> tleguern: thank you for reporting it
20:38 <nipos> So the issue must be directly within the translation files but unfortunately I can't find them
20:39 <clime> maybe we can file issues here? https://git.linux-kernel.at/oliver/ivatar
20:39 <sumpfralle4> sounds good to me
20:39 <clime> ok, i will file the mailgun one
20:40 <tleguern> nipos: ivatar/ivataraccount/templates/login.html in the latest git checkout
20:40 <tleguern> For me the line is: <label for="id_username">{% trans 'Benutzername' %}:</label>
20:41 <nipos> Oh,right.I looked into the new account file
20:43 <sumpfralle4> In the last meeting we started to discuss about the "fallback to gravatar" feature. But we postponed the discussion, since the meeting was already quite long. Should we continue the discussion today, even though fmarier and ofalk are not around? (fmarier described his position; ofalk did that partly (in disagreement)).
20:43 <nipos> Fixed: https://git.linux-kernel.at/oliver/ivatar/merge_requests/65
20:43 <clime> https://git.linux-kernel.at/oliver/ivatar/issues/11
20:44 <sumpfralle4> very quick! :)
20:44 <tleguern> Nice !
20:44 <clime> it's not the best ever place to report it but anyway...should work
20:45 <tleguern> sumpfralle4: Discussing it is moot if they are not there I think.
20:45 <nipos> There's another interesting idea I'd like to talk about today
20:45 <tleguern> Although I have my opinion too.
20:45 <sumpfralle4> tleguern: I agree to postponing. I just wanted to mention it :)
20:46 <sumpfralle4> nipos: please share!
20:46 <nipos> Everyone read this mail? [Libravatar-fans] e.g. ".well-known/avatars" as an alternative/addition to DNS SRV for federated libravatars?
20:46 <tleguern> Yes
20:46 <nipos> It's not mine but I read it and found it very interesting
20:46 <clime> didn't read it sry, will read now
20:47 <clime> but don't mind me
20:47 <tleguern> It can't really replace DNS SRV from my point of view, as one already need to know the domain to query the well-known URL.
20:48 <sumpfralle4> Is it supposed to define "the" server delivering avatar pictures for the users of a mail domain?
20:48 <nipos> I wouldn't completely replace it but only add an alternative solution meaning if the DNS record isn't there,look at WebFinger
20:49 <tleguern> I will have to dig a bit further into WebFinger then.
20:49 <tleguern> If it can helps Javascript clients accessing federated libravatar servers then I am all in :)
20:50 <tleguern> (As they can't do DNS queries)
20:50 <nipos> Yes,it's meant to define the url of the avatar and the /.well-known thing should be on emaildomain.com/.well-known
20:51 <nipos> Javascript is still difficult as it can't read files on other servers except when a Access-Control-Allow-Origin is set
20:51 <tleguern> Yes, and it can't easily query an SRV record.
20:52 <sumpfralle4> Does this approach try to move the libravatar-support from the server/service to the client-side frontend code?
20:53 <sumpfralle4> thus: instead of / in addition to support within services (server-side), it would allow support in frontend code?
20:53 <nipos> Not really.We're talking about use in Javascript which means client side but the .well-known thing is meant for servers normally,too
20:54 <tleguern> The original email actualy mentions a few things :
20:54 <nipos> Only if the server which sends the /.well-known response sends a CORS Header,Javascript support would be possible
20:55 <tleguern> So it doesn't really solve the problem.
20:55 <nipos> Nope
20:57  * sumpfralle4 is curiously waiting for the outcome of the debate
20:57 <tleguern> Not sure if there is one yet.
20:58 <tleguern> I added the RFCs mentionned in the original email to my TOREAD list
20:58 <tleguern> If it can at least help a bit Javascript clients it is still interesting to look at.
20:58 <tleguern> But I can only complement the current DNS based method.
20:59 <sumpfralle4> "I" -> "it"?
20:59 <tleguern> Yes sorry
20:59 <sumpfralle4> :)
20:59 <sumpfralle4> So it sounds like you will dig a bit deeper, so the we can continue with the discussion on the mailing list?
21:00 <tleguern> fine for me
21:00 <sumpfralle4> ("you" -> tleguern, nipos or whoever is interested)
21:00 <nipos> If we say in our docs that /.well-known MUST respond with a Access-Control-Allow-Origin: * header,Javascript support would be possible
21:00 <tleguern> Which seems fine to me.
21:01 <sumpfralle4> "the docs" is currently the wiki - right?
21:01 <tleguern> Yes
21:01 <nipos> Yes
21:02 <sumpfralle4> Since this would be an improvement/extension of the current specification, we should probably discuss and finalize it on the mailinglist.
21:03 <nipos> For a example well-known entry have a look at https://mastodon.social/.well-known/host-meta
21:03 <tleguern> While we are talking about the doc, I started to write separate tests to check the API conformance. Well, the old implementation is quite permissive.
21:04 <tleguern> It doesn't even respects the documented limits to an image size.
21:05 <sumpfralle4> So it sounds like your tests should test for API compliance - and ofalk can work on fulfilling these requirements against your tests?
21:07 <tleguern> I think ivatar is more strict right now, which is not a bad thing.
21:08 <sumpfralle4> sounds good
21:08 <nipos> It also shouldn't be too strict as we could break existing implementations then
21:10 <tleguern> It doesn't accept a query with ?size=0. The old implementation returns a 1x1 image to this.
21:10 <nipos> That's ok.A image in that size doesn't make sense anyway
21:11 <tleguern> Well, I publish my tests and their current results on the mailing list and we will be able to decide which ones are good.
21:11 <nipos> Good
21:12 <sumpfralle4> +1
21:12 <sumpfralle4> Any other topics?
21:13 <tleguern> Last time we received the late visit of Unit193 but you were all already gone.
21:13 <tleguern> He wants to help with testing if I remember correctly.
21:14 <Unit193> tleguern: Howdy.  I have a tiny cgit installation that I use libravatar with, so yeah.  Not sure there's much I can do, but still willing to poke around.
21:14 <Unit193> Spoke to ofalk about some of the OpenID stuff, it's quite nice.
21:18 <sumpfralle4> ofalk will surely appreciate your feedback, when you try your client against the new implementation
21:18 <tleguern> This is a part I don't use so you are more than welcom to test OpenID interactions.
21:21 <sumpfralle4> ok - so I think, we are finished with the meeting? The next one will be on the 25th of November.
21:21 <Unit193> tleguern: I mainly use it as a method to login, my only idea was easy buttons for commonly used login services.
21:23 <tleguern> Ok sumpfralle4.
21:24 <tleguern> Thank you all then, and see you next time :)
21:24 <sumpfralle4> yeah!
21:25 <Unit193> Now that it's done, I note that the different default avatars are explained better on the gravatar API docs (specifically, how they're generated) also while it's utterly unimportant, seems this is an option too: https://robohash.org/
21:26 <tleguern> Unit193: this is a point we decided not to discuss today as two persons are missing.
21:26 <Unit193> Sure thing.
21:27 <tleguern> Currently libravatar redirects default avatars to Gravatar
21:27 <tleguern> That's why they are better explained there.
21:27 <tleguern> If you are looking for these there is also https://unicornify.pictures/
21:27 <Unit193> Ooooh, so just a documentation problem, cool.