FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-21-2010, 06:28 PM
Ananda Samaddar
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

Dear Arch community,

I thought I'd post a follow up on some of the things said in the last
thread I created on this list. I'm using upper case for headings just
to make things easier to read and not to shout! Please post or cc all
follow ups to the Arch General list, and read this message carefully
before replying.

1. DISCUSSION ABOUT SECURITY ON ARCH-GENERAL AND THE GOOGLE GROUP

It's been mentioned that because my proposition for an arch-security
list was rejected, I'm trying to circumvent that by posting stuff about
setting up a security team to arch-general. That's not my intention.

I am proposing a compromise. Internal communications on security
issues will be kept to the Google Group. An irregular 'newsletter'
will be posted to arch-general when major things are done to keep Arch
users who are not on the Google Group informed. Also when security
alerts do eventually start getting issued they *will* be posted to
arch-general. I believe that all Arch users should benefit from the
work that will be getting done. Doing it this way will keep email
traffic on security issues on arch-general to a minimum.

2. THE RELEVANCE AND USEFULNESS OF AN ARCH SECURITY TEAM.

There's been some murmurings that this undertaking is pointless.
Happily this has mostly come from users and not developers. In fact it
has the direct or indirect support of at least two Arch developers,
Pierre Schmitz and Hugo Doria:

http://www.osnews.com/story/22692/Arch_Linux_Team/page6/

This is just as much an experiment as anything else. It remains to be
seen if setting up an Arch Security team is worthwhile. Evidence based
on other distros seems to point to the fact that it is. If you are not
convinced that's fine, but please provide constructive criticism and
not mindless trolling like suggesting naming a security team after a
Mexican food dish or the British English slang word for buttocks.

If you don't want any part of this, other than the odd email on
arch-general you won't be hindered or pestered in any way.

3. WE NEED YOUR HELP

There is no Arch security team as of now. Hopefully there soon will
be. If you want to help it would be helpful if you have the following
skills or experience:

-Ability to modify PKGBUILDs, rebuild and test packages.
-Know how to patch and compile software
-Are willing to subscribe to several security related mailing lists
-Know basic usage of GPG in email
-Are willing to hang out in the arch-security IRC channel
-Are willing to file bugs in the Arch bug tracker

You don't need to be security guru, just willing to help out, learn and
with a desire to make our favourite Linux distro even better than it
already is.

If you want to help out please subscribe to the Google Group and
submit a message with the subject "I want to join the team", without
quotes.

http://groups.google.com/group/arch-security

If you don't have or don't want to create a Google account, please send
me a personal email and I'll add you to the member list.

4. SCOPE OF THE SECURITY TEAM

It is my intention that at this point, the security team will only deal
with finding and fixing security related issues. This will entail
providing interim pkgbuilds, reporting issues on the bug tracker and
sending out alert notices via email.

All communications to the 'outside world' (emails, wiki articles etc)
from the team will state that (for now) the team's work is completely
unofficial and unsupported by the Arch Developers. This is to avoid
sullying the reputation of the Arch developers.

5. LONG TERM GOALS

Most Arch stuff starts out as external projects than then merge with
the main distro. If our work turns out to be useful, and I hope it
will be, I would like us to become an official Arch Team. We could
then having something like Debian does, with two mailing lists, one for
security discussion and a read only list where announcements are
posted. The details of this remain to be determined as this initiative
is only just starting out.

6. FINAL WORDS

I hope this message has made things a bit clearer for everyone. I
won't start on the actual process/policy documents till after this
weekend coming as I have some things to attend to before that. Of
course feel free to suggest things on the Google Group, I'd like to
make things as open and transparent over there as possible.

If you have any questions, don't hesitate to post on the Google Group
or email me personally.

Thanks,

Ananda Samaddar
 
Old 06-21-2010, 11:11 PM
Ng Oon-Ee
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, 2010-06-21 at 19:28 +0100, Ananda Samaddar wrote:
> 5. LONG TERM GOALS
>
> Most Arch stuff starts out as external projects than then merge with
> the main distro. If our work turns out to be useful, and I hope it
> will be, I would like us to become an official Arch Team. We could
> then having something like Debian does, with two mailing lists, one for
> security discussion and a read only list where announcements are
> posted. The details of this remain to be determined as this initiative
> is only just starting out.

I'd still like to know how this replaces/conflicts with Arch policy for
'as upstream as possible'. I'm aware that just starting out the answer
may just be "we don't know yet", but for me one of the benefits of Arch
is that all packages are close to upstream (and thus its easy to discuss
bugs with upstream, which may not be the case with 5-10 security-patches
from git/svn).
 
Old 06-21-2010, 11:17 PM
Ananda Samaddar
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Tue, 22 Jun 2010 07:11:25 +0800
Ng Oon-Ee <ngoonee@gmail.com> wrote:

> I'd still like to know how this replaces/conflicts with Arch policy
> for 'as upstream as possible'. I'm aware that just starting out the
> answer may just be "we don't know yet", but for me one of the
> benefits of Arch is that all packages are close to upstream (and thus
> its easy to discuss bugs with upstream, which may not be the case
> with 5-10 security-patches from git/svn).
>

I think you answered your own question with the 'we don't know yet'
statement. I'm looking to get in with the archserver.org guys and the
only response I've had so far from them seems to be positive. So the
Google Group may well be shutting down with everything moving to
archserver.org's infrastructure. There's also already one person who
wants to join the team and help.

Basically watch this space and hopefully we'll have something on the go
very soon.

thanks,

Ananda
 
Old 06-22-2010, 01:02 AM
Ng Oon-Ee
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, 2010-06-21 at 18:47 -0500, C Anthony Risinger wrote:
> On Jun 21, 2010, at 6:37 PM, Andres P <aepd87@gmail.com> wrote:
>
> > 2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
> >> bugs with upstream, which may not be the case with 5-10 security-
> >> patches
> >> from git/svn).
> >
> > This is just pessimistic outlook. Having patches means that you're
> > actually
> > contributing upstream instead of leaching the latest ver every 3
> > weeks.
> >
> > People need to stop with the notion that patching is bad. As long as
> > you submit
> > upstream, it's anything but a detriment. Upstream *wants* you to fix
> > their
> > crap.
> >
> > Andres P
>
> He said from git/svn... ie backporting, not contributing.
>
> C Anthony

Thanks Anthony. I guess my statement IS unclear.

@Andres I agree that contributing patches upstream is ideal, but
(pessimistic outlook again) I doubt the size of the security team will
be enough to allow them to write and test significant patches, which
leads to the assumption that their main job would be to identify holes
and grab patches from upstream (or Fedora/Debian/whatever) to fix those
holes while waiting for upstream to go through whatever verification
process they need. Those patches would come from a patchwork of places
(upstream's git/svn, fedora/debian patch, etc.), and make it a bit
harder to keep things stable.
 
Old 06-22-2010, 01:37 PM
Ananda Samaddar
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Tue, 22 Jun 2010 13:16:23 +1000
"Allan McRae" <allan@archlinux.org> wrote:
>
> The point is that the developers around here already patch for
> security issues. The only change that I think that a security team
> will achieve is to notify me (as a developer) of issues that I have
> overlooked on the upstream mailing lists and file a bug report. It
> is a bonus if the issue is pre-analyzed for me and all relevant links
> supplied so I can assess it quickly myself and release a fixed
> package if I deem that being suitable.
>
> Allan

This is exactly what we plan to do, with the addition of providing
interim PKGBUILDs (with a disclaimer that they are unofficial) and
announcements when a security related bug is fixed by a package update.
Such interim PKGBUILDs would be peer-reviewed by the Security Team and
submitted with the relevant bug report to aid the package maintainer. I
can't see how this is not useful. It will also lighten the workloads
of the devs and package maintainers.

Ananda
 
Old 06-22-2010, 11:49 PM
Allan McRae
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On 23/06/10 05:21, C Anthony Risinger wrote:


example: SSH 0-day exploit is released. bang! you crack out your
interim PKGBUILD and crack a beer because your safe right? whoops,
because this is a production machine (from a message a couple hours
ago):

On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian
<ingeniware@gmail.com> wrote:

..........
Everything work fine, but I'm doing updates only ones in 2-3 months.
..........


what?? so i have to also upgrade lib XYZ to get this to work? wait,
let's just backport to version X... damn! Sandy Squirrel updated a
month ago, so she's running version Y...

do you see where i'm headed here? are you going to provide fixes for
every possible package update that occurred in the last 6 months?
lets say your crazy and you auto update your production machines...
now your pulling in a _reactionary_ fix that if appropriate will
probably be in upstream in less than a week, and they'll have a
security related point-release to address it properly.


What a load of crap... Arch developers only support packages that are
currently in the repo. Why would the security team do anything else. If
a person is not prepared to update their system regularly, or at least
when there is a known security issue in the out-of-date packages they
are using, then they should be using a different distribution that makes
stable snapshot releases.


Also, as established earlier in the thread, some of our packages have
patches for security issues that a a couple of years old because
upstream has not made a new release. So the whole probably be fixed by
upstream in less that a week and a point release made is just naive.


Finally, this is not going to change the way development works around
here. We would still be patching the software for the security bugs. It
will just save the developers more time assessing bug as all the
necessary information/links will be provided for us in one spot.


Allan
 
Old 06-23-2010, 01:56 AM
Isaac Dupree
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On 06/22/10 19:49, Allan McRae wrote:

Also, as established earlier in the thread, some of our packages have
patches for security issues that a a couple of years old because
upstream has not made a new release. So the whole probably be fixed by
upstream in less that a week and a point release made is just naive.


On 06/22/10 15:21, C Anthony Risinger wrote:

i just am having a hard time believing that you
are not only going to track down holes, but have the competence to
properly fix them, for all the reasons i've already specified.


part of the situation is, lots of upstreams don't have security
competence either -- especially volunteer-run projects, but I bet some
commercial undertakings don't either. So they don't make point-releases
as soon as an important security issue is discovered; or they make a
patch but the patch is incorrect (often established distros have, in
some ways, a better sense of how to patch a security flaw than a
individual upstream because the distros see a lot of security flaws --
like buffer overruns, etc).


It's clear that spreading more information more quickly about security
issues sounds productive, (as long as the information is as correct as
can be, which a volunteer team may be able to have some fair amount of
competence at, I'm guessing)


-Isaac
 

Thread Tools




All times are GMT. The time now is 11:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org