On Thu, 2015-04-09 at 18:17 +0200, Ansgar Burchardt wrote:
> as I don't think we'll currently shorten the time Release is valid for,
> I'm closing the bug report as suggested by the submitter[1].
For the records, my suggestion was not based on the issue being fixed or
not an issue, but rather the
Hi Ian.
In principle I've had left this discussion for previously stated
reasons, but since you're one of the few who actually seems to be
willing to discuss about this on a technical level with real arguments
and ideas some replies to them:
On Mon, 2014-11-03 at 17:56 +, Ian Jackson wrote:
Santiago Vila writes ("Re: Bug#752450: ftp.debian.org: please consider to
strongly tighten the validity period of Release files"):
> I have a laptop with testing which I use mostly on weekends. I have a
> partial mirror there, which I try to update as soon as I login into
> t
Hey,
I'd think everything about this attack vector has been exhaustively
discussed now from security and technical point of views and since all
concerns and their possible solutions lay quite obviously at the desk.
Jörg, AFAICS you've been the only one of the FTP masters that was
contributing to
More to the point:
If we want testing to be "constantly usable" (as opposed to "mostly useless
if you don't apt-get update in a week"), the expiration time for the
Release file should be a lot closer than the one used for stable and
far away than the one used for unstable.
Thanks.
--
To UNSUBS
Dear ftpmasters:
Contrary to what this report suggests, I believe the current validity
of 7 days for testing and unstable is extremely low and should be
increased.
I have a laptop with testing which I use mostly on weekends. I have a
partial mirror there, which I try to update as soon as I login
Hey.
Some more technical on this:
Right now, we get the validity via the fields in the Release files.
I'm not sure whether the following could actually help with the
technical issues (i.e. speed of distributing re-signed release files
across the mirrors), but perhaps basing the validity on the O
Hey Henrique, et al.
I've had lost my interest a bit, since it feels like fighting
windmills... but one month has passed and it's perhaps a good time to
revisit this.
On Mon, 2014-09-29 at 08:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote:
> >
On Thu, 2014-09-25 at 21:56 +0200, Joerg Jaspert wrote:
> It also sounds quite stupid that suddenly all users have no working
> mirror anymore, should there be an outage of ftp-master or
> security-master longer than the signing time.
Well I don't see why this must necessarily happen.
Even if ftp-
On Fri, 2014-09-26 at 11:20 +0800, Paul Wise wrote:
> snapshot is a read-only (modulo cosmic rays and removal of
> non-redistributable things) historical record, files in it will not be
> modified to re-sign with newer keys nor to update Valid-Until.
So what would you do now, when one of the past
Package: snapshot.debian.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
On Sun, Sep 28, 2014 at 4:34 AM, Peter Palfrader wrote:
> On Fri, 26 Sep 2014, Paul Wise wrote:
>
>> On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote:
>>
>> > Well I think snapshot is it's o
On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote:
> Well I think snapshot is it's own construction site, isn't it?
snapshot is a read-only (modulo cosmic rays and removal of
non-redistributable things) historical record, files in it will not be
modified to re-sign with newer keys
On 13710 March 1977, Christoph Anton Mitterer wrote:
>> I'm not sure going below a dinstall cycle is useful. Probably even two.
>> Have it expire before the new stuff even got a chance to get out is not
>> a good idea, IMO.
> Are there any numbers how long it actually takes for the stuff to get
> d
On Mon, 2014-09-15 at 00:04 +0200, Stefan Lippers-Hollmann wrote:
> Please consider that too short intervals (24h might still work, but
> it's hard on the limit) make non-primary (cron based) mirrors basically
> impossible. Including local mirrors used for systems that can't connect
> to the int
Hey Joerg.
On Sun, 2014-09-14 at 21:52 +0200, Joerg Jaspert wrote:
> Technically we could go down to 1 second, validtime is expressed in
> seconds in our setup.
;-)
> > My proposal would be something like that:
> > unstable/testing: 4-12 hours
> > [wheezy|squeeze]/updates at security.d.o: 1-6 h
On Sun, Sep 14, 2014 at 09:52:00PM +0200, Joerg Jaspert wrote:
> Also, going down to such small intervals means we MUST resign, even if
> there is no update at all in the archive (so an extra cronjob, just to
> be sure). That's no problem in the main archive, there is always enough
> going on, but
Hi
On Sunday 14 September 2014, Joerg Jaspert wrote:
> On 13616 March 1977, Christoph Anton Mitterer wrote:
>
> [ Not doing a full quote, but keeping quite a bit of context for
> debian-devel readers ]
>
> > As Jakub Wilk pointed out[1] these are the current validity periods
> > for Release fi
On 13616 March 1977, Christoph Anton Mitterer wrote:
[ Not doing a full quote, but keeping quite a bit of context for
debian-devel readers ]
> As Jakub Wilk pointed out[1] these are the current validity periods
> for Release files:
> unstable, experimental: 7 days
> testing: 7 days
> wheezy:
Package: ftp.debian.org
Severity: important
Tags: security
Dear ftp masters.
I've thought about that before but then forgot it again and it came
back to my mind during the recent thread[0] about security, that
I've started on debian-devel.
As Jakub Wilk pointed out[1] these are the current val
19 matches
Mail list logo
