On 31/10/13 16:12 +0100, Mathias Behrle wrote:
> > Cédric Krier <cedric.krier@b2ck.com> added the comment:
> >
> > So I propose this scheduling:
> >
> > - security release the 3rd November (applying the patch and release tryton)
> > - publish a news the 4th November (to let packager update their repositories)
>
> I would recommend to not schedule any important dates on weekend days. People
> working for distributions don't necessarily work on those days.
The opposite applies also: people working for distributions don't
necessarily work on the week.
In many projects I follow I see people more active the weekend.
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
> So I propose this scheduling:
>
> - security release the 3rd November (applying the patch and release tryton)
> - publish a news the 4th November (to let packager update their repositories)
I would recommend to not schedule any important dates on weekend days. People
working for distributions don't necessarily work on those days.
@ajacoutot, @ced: Could you please share the information published on OpenBSD
ports? Was a CVE assigned via OpenBSD?
So I propose this scheduling:
- security release the 3rd November (applying the patch and release tryton)
- publish a news the 4th November (to let packager update their repositories)
The security release will contain this fix and the other fixes already
backported on today (they are all older than 1 week).
> Do we do a quick security release or we just let the fix join the next
maintenance release?
Maintenance releases just were done and the next seem too far away for me. I
would prefer a security release.
On 30/10/13 19:57 +0100, Mathias Behrle wrote:
> AFAIS a malicious server could play with ssh keys, authorized_keys of the user
> etc..
I'm not sure to follow you.
> Being not sure I tend to evaluate this as a security fix deserving a CVE.
I tend to think like you.
Do we do a quick security release or we just let the fix join the next
maintenance release?
AFAIS a malicious server could play with ssh keys, authorized_keys of the user
etc.. Being not sure I tend to evaluate this as a security fix deserving a CVE.
@ajacoutot, I see that you already pushed (and make public) this security issue
on OpenBSD ports. The idea behind this issue is to synchronize the publication
of security fixes.
@all, what do we do? Are we doing a security release with this fix this week?
does it deserve a CVE?
I have discovered that the file extension received from the server to store
temporary the report and open it is not correctly sanitized.
It means that a malicious server could send as result of a report and extension
that could contain filesystem path separator. So it can force the client to
write any files on the client host with the right of the user.
Here is a patch that fixes the issue.
I don't know if it deserves the label of security fixes or if it should follow
the normal path as it requires to connect to a malicious server.