Hi!
Thanks for the fruitful discussions on this mail thread and today in IRC.
Highly appreciated.
For the moment, I'll leave the idea with API keys alone.
For those who have privacy concerns, we can redirect them to the following
example script now:
On 3/12/19 2:23 PM, Oliver Falk wrote:
> Yes, federation wouldn't work - only if we do not encrypt the hash, but
> instead the mail-address (makes sense, since it's anyway encrypted) and
> Libravatar proxies the requests to the federated site. Which means, that
> these sites would only need to
On 2019-03-12 at 15:23:31, Oliver Falk wrote:
> BTW. That raises the question in my mind do we know how many sites actually
> run their own Libravatar (compatible) service? I guess no!? @Francois Marier
> do you know anything?
If you mean how many sites expose their own Libravatar endpoints via
On Tuesday, 12 March 2019, clime wrote:
>
>
> On Tuesday, 12 March 2019, Oliver Falk wrote:
>
>> Hey.
>>
>> Thanks Tristan for bringing it to the point. :-)
>> Yes, federation wouldn't work - only if we do not encrypt the hash, but
>> instead the mail-address (makes sense, since it's anyway
On Tuesday, 12 March 2019, Oliver Falk wrote:
> Hey.
>
> Thanks Tristan for bringing it to the point. :-)
> Yes, federation wouldn't work - only if we do not encrypt the hash, but
> instead the mail-address (makes sense, since it's anyway encrypted) and
> Libravatar proxies the requests to the
Hey.
Thanks Tristan for bringing it to the point. :-)
Yes, federation wouldn't work - only if we do not encrypt the hash, but
instead the mail-address (makes sense, since it's anyway encrypted) and
Libravatar proxies the requests to the federated site. Which means, that
these sites would only
On 3/12/19 12:59 PM, clime wrote:
> I am missing the point encrypting the hash. I could understand it for
> md5, which is crackable nowdays but not quite for sha256. That hash
> should be non-reversible in practical terms and then we can always just
> jump to sha512 in a few years when hardware is
Hi!
OK. I forgot to add the reference:
https://bugs.launchpad.net/libravatar/+bug/1248456
I hope that clears things up! :-)
Basically, if all sites with security in mind would use keys to retrieve
the images, that would lead to the situation, where you cannot simply hash
an e-mail/openid
On Tue, 12 Mar 2019 at 12:29, Oliver Falk wrote:
> Hi!
>
> So, the basic idea, that I already implemented as PoC, is. You request API
> keys and get a public and a secret key. You use the secret key to 'encrypt'
> the user hash. Eg.:
>
>
Hi!
So, the basic idea, that I already implemented as PoC, is. You request API
keys and get a public and a secret key. You use the secret key to 'encrypt'
the user hash. Eg.:
ConfirmedEmail.objects.first().encrypted_digest(secret_key=APIKey.objects.first())
would return something like this:
On Mon, 11 Mar 2019 at 19:02, Oliver Falk wrote:
> Hi!
>
> Since I got no reaction on IRC, I'm posting this here as well and would
> love to gather feedback:
>
> quick poll. fr the people who are eventually are around. if we
> implement something like api-keys (public/private key), that will be
Hi!
Since I got no reaction on IRC, I'm posting this here as well and would
love to gather feedback:
quick poll. fr the people who are eventually are around. if we
implement something like api-keys (public/private key), that will be used
for encryption and therefore no longer reveal the mail
12 matches
Mail list logo
