On Mon, Dec 01, 2014 at 04:55:55AM +0100, Christoph Anton Mitterer wrote:
On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote:
Except that if a firewall protects a user from using their printer
(random example, not sure how likely)
Well most security guys are probably sceptical about
On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote:
Except that if a firewall protects a user from using their printer
(random example, not sure how likely)
Well most security guys are probably sceptical about any automagical
confiugration of things like a printer... so protects can
On Sat, Nov 22, 2014 at 11:42:41AM +0100, Wouter Verhelst wrote:
[...]
Before we enable a firewall by default, we should, IMO, have the
following:
- A way for a user to configure it without understanding iptables.
- A way for a user to debug (without understanding iptables) if things
On Sun, Nov 02, 2014 at 12:37:06PM +0100, Ralf Jung wrote:
Hi,
- Debian should ship a default set of firewall rules. Are we the only
distro which doesn't do this? I mean a basic ruleset which drops
incoming, accepts outgoing and accepts related,establised is so easy to
do... and it
Paul Wise p...@debian.org writes:
On Tue, Nov 4, 2014 at 1:56 AM, Ian Jackson wrote:
...
* We might want automation which was capable of automatically
shutting a server down into some kind of minimal maintenance mode,
when it is unable to verify its own security support status.
That
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
the system.
Firstly, I
[Dropping the bug, this is beginning to get OT]
On Tue, Nov 4, 2014 at 1:56 AM, Ian Jackson wrote:
* We could run a lightweight polling service on Debian infrastructure
which the computer could use to find out how out of date it is.
This makes me think of the AMQP stuff DSA has setup as
On Sat, Nov 01, 2014 at 07:46:42PM +0100, Philipp Kern wrote:
On Thu, Oct 30, 2014 at 05:52:07PM +0100, Christoph Anton Mitterer wrote:
- Debian should ship a default set of firewall rules. Are we the only
distro which doesn't do this? I mean a basic ruleset which drops
incoming, accepts
Hi,
- Debian should ship a default set of firewall rules. Are we the only
distro which doesn't do this? I mean a basic ruleset which drops
incoming, accepts outgoing and accepts related,establised is so easy to
do... and it would help for all those cases where services are started
but not
❦ 2 novembre 2014 12:37 +0100, Ralf Jung p...@ralfj.de :
However, it should be possible to create a tool which helps novice users
in managing their firewall, and such a tool could be installed by
default on at least a Desktop installation. If we go down that route,
and if said tool is easy
On Thu, Oct 30, 2014 at 05:52:07PM +0100, Christoph Anton Mitterer wrote:
- Debian should ship a default set of firewall rules. Are we the only
distro which doesn't do this? I mean a basic ruleset which drops
incoming, accepts outgoing and accepts related,establised is so easy to
do... and it
* Christoph Anton Mitterer cales...@scientia.net [141030 05:10]:
To be honest, it's really awkward to see how much all this is apparently
fought against.
You have been told again and again that what you suggest would make the
whole thing less useable to the point that it reduces security for
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
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
On Thu, Oct 30, 2014 at 06:21:52PM +0100, Christoph Anton Mitterer wrote:
On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote:
I would hope Debian never becomes a truly security conscious
distribution by that definition.
It implies the distribution thinks it
knows better than its
On Thu, 2014-10-30 at 01:40 -0400, Michael Gilbert wrote:
There are also end-of-life announcements, which maybe the
debian-security-support package now addresses in a somewhat automated
fashion.
I wasn't aware of that. Thanks.
Anyway, it is entirely understandable that reading can be hard,
Russ Allbery writes (Re: Bug#752450: ftp.debian.org: please consider to
strongly tighten the validity period of Release files):
Russell Stuart russell-deb...@stuart.id.au writes:
If there are two ways and one requires a human and the other is
completely automatic, all other things being
On Thu, Oct 30, 2014 at 03:59:33PM +1000, Russell Stuart wrote:
On Thu, 2014-10-30 at 01:40 -0400, Michael Gilbert wrote:
Anyway, it is entirely understandable that reading can be hard, but at
a minimum the truly security-conscious need to be to do so.
Yes, fine. But a truly security
Hey again.
On Wed, 2014-10-29 at 22:07 -0700, Russ Allbery wrote:
If you don't read the mail, you're going to miss some really vital
information, like packages that we are no longer supporting. I am very
much opposed to giving people the impression they can just monitor the
security archive
On Thu, 2014-10-30 at 01:29 -0400, Michael Gilbert wrote:
There is also LWN as a mechanism for independent verification.
Don't they just take up the information from Debian themselves?
Although there is often more than a day long delay on that, and more
on weekends
Which makes it inadequate
On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote:
I would hope Debian never becomes a truly security conscious
distribution by that definition.
It implies the distribution thinks it
knows better than its users what the right security trade-off is, and
that way lies disaster.
Isn't
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
Yes, I agree. But for me apt.conf/Max-ValidTime is useless unless the
release file is guaranteed to be updated more frequently than its
Valid-Until: header implies. Is it, and is that undertaking
documented somewhere?
Point. We
Nick Phillips nick.phill...@otago.ac.nz writes:
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
Point. We should have documentation for what the minimum signing
frequency we guarantee is, particularly for the security archive.
Then, people who are willing to suffer from mirror issues
Show me the patches.
On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote:
On Thu, Oct 30, 2014 at 03:59:33PM +1000, Russell Stuart wrote:
Yes, fine. But a truly security conscious distribution doesn't depend
on its users being truly security conscious.
I would hope Debian never becomes a truly security
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:
Christoph Anton Mitterer cales...@scientia.net writes:
Anyway this should demonstrate quite practical, how fast attackers are
these days and that severely reducing the validity times doesn't just
help against some completely unreal attack vectors.
Even if the security team is as fast as
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
But we shouldn't confuse that with the right way to check
for security updates for Debian systems. People who
care about security updates need to be subscribed to
debian-security-announce and reading the DSAs.
If there are two ways and
Hey Russ.
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
Packages appearing on mirrors is not how we notify Debian users of
security updates. We do that by issuing a security advisory.
Aha,... well... sounds like nitpicking,... I guess the least of the
users have subscribed the
Russell Stuart russell-deb...@stuart.id.au writes:
If there are two ways and one requires a human and the other is
completely automatic, all other things being equal for me the right
way is the automated one. I know my limitations - not being
conscientious when doing manual repetitive labour
Christoph Anton Mitterer cales...@scientia.net writes:
Even apart from the above problems, I doubt that mail is the appropriate
mean for many admins to get notified about security upgrades.
If you don't read the mail, you're going to miss some really vital
information, like packages that we
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
Also, this means that you completely miss security advisories that *don't*
involve changing a package in the archive, like this thing is a disaster,
so we're pulling it from the archive entirely and suggest you stop using
it.
If it is so
Russell Stuart russell-deb...@stuart.id.au writes:
If it is so that much of a disaster that it warrants pulling a package
from stable, surely a little more notification than an email to a list
most people don't monitor would be warranted?
See, for example, DSA-2819. Or, on a different front,
On Thu, Oct 30, 2014 at 12:09 AM, Christoph Anton Mitterer wrote:
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
Packages appearing on mirrors is not how we notify Debian users of
security updates. We do that by issuing a security advisory.
Aha,... well... sounds like nitpicking,... I
On Thu, Oct 30, 2014 at 1:12 AM, Russell Stuart wrote:
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
Also, this means that you completely miss security advisories that *don't*
involve changing a package in the archive, like this thing is a disaster,
so we're pulling it from the
On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote:
Now to deal with your concern of larger outages:
2) Just because there are no valid [In]Release* files, it doesn't mean
that those mirrors and their repositories can't be used any longer. The
data is still there as it was before.
An
Hi,
So, can we get now some alternative proposals that address the fact that
some mirrors need 48H validity, and many leaf mirrors really want at least
a week?
How about Security updates are published on security.d.o, so _that_
archive's validity might as well be 50h or so; anything else will
On Mon, 29 Sep 2014, Matthias Urlichs wrote:
So, can we get now some alternative proposals that address the fact that
some mirrors need 48H validity, and many leaf mirrors really want at least
a week?
How about Security updates are published on security.d.o, so _that_
archive's validity
Package: snapshot.debian.org
Severity: wishlist
X-Debbugs-CC: debian-devel@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 own
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
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
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 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
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 hours
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
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
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 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: no
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 files:
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
49 matches
Mail list logo
