libravatar-fans team mailing list archive

[Francois Marier <francois@xxxxxxxxxxx>]

On 2012-08-02 at 10:58:28, Jonathan Harker wrote:
> I wonder if we should cap file size as well, perhaps as a multiplier of
> maximum size, in case some folks start uploading massive animated
> PNGs, c.f.

There's a setting for that in libravatar/settings.py:

  MAX_PHOTO_SIZE

It's currently set to 5MB on libravatar.org.

> >>>2. Invalid input in the  hash It should be stated that the "md5
> >>> hash detection" is purely a check if the hash is 32 chars, while
> >>> sha256 hashes are 64 chars long.
> >> Is that relevant to implementers or regular developers?
> >
> > Only relevant to people implementing their own server, not for
> > users.
> 
> Are there any weird safety or security issues we should worry about
> around also restricting hash characters to [a-z0-9] as well, and return
> 400 if it looks fishy? For some reason the words buffer underrun
> spring to mind.

I can't think of any, but of course that doesn't mean there aren't any :)

> >The use case for different  modes ... maybe I've implemented a cool
> > new way to generate dynamic avatars, similar to monsterids - ponyid
> > for example. Do I want to wait for the libravatar spec to be updated?
> > This does not scale.
> 
> Maybe we should discuss support for mode plugins? I think the mode
> was originally only there so one could still have an avatar image
> without uploading anything, but I may be wrong (François?)

What exactly do you mean by plugin in this case? A different algorithm
(e.g. pony generator) for returning nobody images?

> I agree in principle, bearing in mind we will have to think about folks
> potentially faking IDs by blindly redirecting.

I'm not sure I follow you here... What "IDs" are you referring to?

> > Thinking about that I've come to the conclusion that two docs would
> > be nice: First the specification, which explains in clear, hard, dry
> > words how clients and servers need to behave.
> 
> With all that RFC MUST SHOULD MAY etc. I agree. In fact, perhaps we
> should write it up as an RFC :-) I'm happy to give it a crack. We should
> use Sphinx. Sphinx is ace.

If you want to lead this, that would be really cool. You're a documentation
star :)

Should we use an etherpad for it?

Cheers,
Francois

-- 
Francois Marier           identi.ca/fmarier
http://fmarier.org      twitter.com/fmarier