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, 11:37 PM
Andres P
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

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
 
Old 06-21-2010, 11:47 PM
C Anthony Risinger
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

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
 
Old 06-21-2010, 11:53 PM
Andres P
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@extof.me> wrote:
> He said from git/svn... ie backporting, not contributing.
>

...?

Once they're in svn they're confined to abs? Besides, it's not like there's
anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor
Arch's svn repo, etc.

Andres P
 
Old 06-22-2010, 02:07 AM
C Anthony Risinger
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, Jun 21, 2010 at 6:53 PM, Andres P <aepd87@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@extof.me> wrote:
>> He said from git/svn... ie backporting, not contributing.
>>
>
> ...?
>
> Once they're in svn they're confined to abs? Besides, it's not like there's
> anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor
> Arch's svn repo, etc.
>
> Andres P

i'm not trying to discourage anyone from pursuing an 'arch security
team', or whatever you want to call it. as someone who makes their
living writing softwares, you cannot just whip up comprehensive
patches for any old project; it takes a significant amount of time to
learn the codebase.

now the alternative; pulling in obscure fixes from here and there that
you don't even really understand to repair problems that may only
exist for a short while, or may not even been real problems is a
fool's errand. how do you know _why_ upstream wrote the code the way
they did? are you sure it's really a bug/hole? are you sure when you
backport stuff from trunk/head you won't be introducing more/worse
holes? are you sure the backported commit doesn't depend on other
commits that currently only exist in trunk? do you trust other
distros, ie not authors, to make these decisions for you?

one of my favorite things about Arch is not just following the latest
releases of upstream, but trying to follow the latest _configuration_
of upstream as well. no one knows a software's internals better than
the people who wrote it; let me decide how to make it fit in my
environment, because _i_ know that better.

dropping privileges and things like that _is_ good practice... but as
i said in the other thread: _ultimately_, security is the duty of
those deploying to production, not those writing software or packaging
it for a generic audience. sure, you could run every application in
an LXC container by default with a private rootfs/namespaces, and slap
some smack policies or grsecurity or whatever fancy pants layers of
indirection you conceive... but should the other 99% of users have to
deal with that level of paranoia, and have to undo all that junk when
it's not what they need? no.

upstream may allow the ability to automatically run in a
chroot/container/etc., but it's never the default. why? it's not
their job to know how you intend to deploy. it's not Arch's job
either.

my point of this ramble if there is one, is that personally, i don't
want _anyone_ other than upstream to make security decisions regarding
their software. if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long.
even if an security hole is found i _don't_ want the fix to be
included by default, unless it came from upstream in the form of a new
release, which Arch would just pick up as usual.

thus, in my opinion, an 'arch security team' would be most effective
by limiting itself to:

1) alerting others that wish to be alerted of any
known/potential/outstanding holes
2) making sure upstream is aware, and getting an ETA of inclusion into mainline
3) adding many wiki pages on how to lock down daemons/applications +
best practices
4) making sane recommendations to the development team that does _not_
include patches of any kind or wild changes to default configurations

if they stick to that, i'm all about it; otherwise, they're just in the way.

C Anthony
 
Old 06-22-2010, 03:16 AM
"Allan McRae"
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On 22/06/10 12:07, C Anthony Risinger wrote:

my point of this ramble if there is one, is that personally, i don't
want _anyone_ other than upstream to make security decisions regarding
their software.if Arch started naively backporting stuff based of

> the latest alert from XYZ, i wouldn't be sticking around to long.
> even if an security hole is found i _don't_ want the fix to be
> included by default, unless it came from upstream in the form of a new
> release, which Arch would just pick up as usual.


Then you should probably move along...

> find /var/abs -name *CVE*
/var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
/var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
/var/abs/extra/alpine/CVE-2008-5514.patch
/var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
/var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
/var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
/var/abs/core/expat/CVE-2009-3720.patch
/var/abs/core/expat/CVE-2009-3560.patch

and these are just the patches named for the security issue they fix.

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
 
Old 06-22-2010, 03:27 AM
C Anthony Risinger
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
> On 22/06/10 12:07, C Anthony Risinger wrote:
>>
>> my point of this ramble if there is one, is that personally, i don't
>> want _anyone_ other than upstream to make security decisions regarding
>> their software.if Arch started naively backporting stuff based of
>
>> the latest alert from XYZ, i wouldn't be sticking around to long.
>> even if an security hole is found i _don't_ want the fix to be
>> included by default, unless it came from upstream in the form of a new
>> release, which Arch would just pick up as usual.
>
>
> Then you should probably move along...
>
>> find /var/abs -name *CVE*
> /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
> /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
> /var/abs/extra/alpine/CVE-2008-5514.patch
> /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
> /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
> /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
> /var/abs/core/expat/CVE-2009-3720.patch
> /var/abs/core/expat/CVE-2009-3560.patch
>
> and these are just the patches named for the security issue they fix.
>
> 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.

indeed. 2007/8/9? are these patches from years ago, for dead
software (xmms?)? i don't know the state of the others.

alright, so you're patching stuff... why? why are such old patches
not in upstream? if things were done appropriately there wouldn't be
a need for intermediary patches because glaring security holes are
quickly absorbed into upstream. or... whats the deal here? i don't
get the need to carry these around.

at any rate i don't agree with it but meh, i'm just a worker bee :-)

C Anthony
 
Old 06-22-2010, 03:53 AM
Dan McGee
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger <anthony@extof.me> wrote:
> On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
>> On 22/06/10 12:07, C Anthony Risinger wrote:
>>>
>>> my point of this ramble if there is one, is that personally, i don't
>>> want _anyone_ other than upstream to make security decisions regarding
>>> their software.if Arch started naively backporting stuff based of
>>
>>> the latest alert from XYZ, i wouldn't be sticking around to long.
>>> even if an security hole is found i _don't_ want the fix to be
>>> included by default, unless it came from upstream in the form of a new
>>> release, which Arch would just pick up as usual.
>>
>>
>> Then you should probably move along...
>>
>>> find /var/abs -name *CVE*
>> /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
>> /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
>> /var/abs/extra/alpine/CVE-2008-5514.patch
>> /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
>> /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
>> /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
>> /var/abs/core/expat/CVE-2009-3720.patch
>> /var/abs/core/expat/CVE-2009-3560.patch
>>
>> and these are just the patches named for the security issue they fix.
>>
>> 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.
>
> indeed. *2007/8/9? *are these patches from years ago, for dead
> software (xmms?)? *i don't know the state of the others.
>
> alright, so you're patching stuff... why? *why are such old patches
> not in upstream? *if things were done appropriately there wouldn't be
> a need for intermediary patches because glaring security holes are
> quickly absorbed into upstream. *or... whats the deal here? *i don't
> get the need to carry these around.
>
> at any rate i don't agree with it but meh, i'm just a worker bee :-)

Do you honestly think releasing software is that easy? It *sucks*. It
is the least enjoyable part of being an open-source developer.

They probably are in upstream and they haven't done a release for some
very good raeson, or upstream is no longer well-maintained. Does that
mean we should leave people vulnerable because of some party line we
have? Heck no.

-Dan
 
Old 06-22-2010, 05:59 AM
C Anthony Risinger
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger <anthony@extof.me> wrote:
>> On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
>>> On 22/06/10 12:07, C Anthony Risinger wrote:
>>>>
>>>> my point of this ramble if there is one, is that personally, i don't
>>>> want _anyone_ other than upstream to make security decisions regarding
>>>> their software.if Arch started naively backporting stuff based of
>>>
>>>> the latest alert from XYZ, i wouldn't be sticking around to long.
>>>> even if an security hole is found i _don't_ want the fix to be
>>>> included by default, unless it came from upstream in the form of a new
>>>> release, which Arch would just pick up as usual.
>>>
>>>
>>> Then you should probably move along...
>>>
>>>> find /var/abs -name *CVE*
>>> /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
>>> /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
>>> /var/abs/extra/alpine/CVE-2008-5514.patch
>>> /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
>>> /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
>>> /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
>>> /var/abs/core/expat/CVE-2009-3720.patch
>>> /var/abs/core/expat/CVE-2009-3560.patch
>>>
>>> and these are just the patches named for the security issue they fix.
>>>
>>> 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.
>>
>> indeed. *2007/8/9? *are these patches from years ago, for dead
>> software (xmms?)? *i don't know the state of the others.
>>
>> alright, so you're patching stuff... why? *why are such old patches
>> not in upstream? *if things were done appropriately there wouldn't be
>> a need for intermediary patches because glaring security holes are
>> quickly absorbed into upstream. *or... whats the deal here? *i don't
>> get the need to carry these around.
>>
>> at any rate i don't agree with it but meh, i'm just a worker bee :-)
>
> Do you honestly think releasing software is that easy? It *sucks*. It
> is the least enjoyable part of being an open-source developer.
>
> They probably are in upstream and they haven't done a release for some
> very good raeson, or upstream is no longer well-maintained. Does that
> mean we should leave people vulnerable because of some party line we
> have? Heck no.

hmm, so the fundamental problem is that the word 'upstream' implies a
unity that does not exist. at this point i would enter conversation
about reconciling individual 'upstreams' to a common backend, such
that distributions/contributors/users may immediately benefit from
each others work; a p2p application and public software broadcasting
framework upon which distributions could be founded...

a different topic :-)

i suppose... unmaintained should have patches and very small, concise
changes to poorly maintained, and maybe even _very_ few to regularly
maintained. yet, most security related alerts are for higher profile
applications; a more immediate response i would think?

i simply don't want to see a collective effort to preempt upstream; i
prefer to manually digress from vanilla, and i'm probably a minority.

C Anthony
 
Old 06-22-2010, 06:11 AM
"Allan McRae"
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

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

On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee<dpmcgee@gmail.com> wrote:

On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger<anthony@extof.me> wrote:

On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae<allan@archlinux.org> wrote:

On 22/06/10 12:07, C Anthony Risinger wrote:


my point of this ramble if there is one, is that personally, i don't
want _anyone_ other than upstream to make security decisions regarding
their software.if Arch started naively backporting stuff based of



the latest alert from XYZ, i wouldn't be sticking around to long.
even if an security hole is found i _don't_ want the fix to be
included by default, unless it came from upstream in the form of a new
release, which Arch would just pick up as usual.



Then you should probably move along...


find /var/abs -name *CVE*

/var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch
/var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch
/var/abs/extra/alpine/CVE-2008-5514.patch
/var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch
/var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch
/var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch
/var/abs/core/expat/CVE-2009-3720.patch
/var/abs/core/expat/CVE-2009-3560.patch

and these are just the patches named for the security issue they fix.

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.


indeed. 2007/8/9? are these patches from years ago, for dead
software (xmms?)? i don't know the state of the others.

alright, so you're patching stuff... why? why are such old patches
not in upstream? if things were done appropriately there wouldn't be
a need for intermediary patches because glaring security holes are
quickly absorbed into upstream. or... whats the deal here? i don't
get the need to carry these around.

at any rate i don't agree with it but meh, i'm just a worker bee :-)


Do you honestly think releasing software is that easy? It *sucks*. It
is the least enjoyable part of being an open-source developer.

They probably are in upstream and they haven't done a release for some
very good raeson, or upstream is no longer well-maintained. Does that
mean we should leave people vulnerable because of some party line we
have? Heck no.


hmm, so the fundamental problem is that the word 'upstream' implies a
unity that does not exist. at this point i would enter conversation
about reconciling individual 'upstreams' to a common backend, such
that distributions/contributors/users may immediately benefit from
each others work; a p2p application and public software broadcasting
framework upon which distributions could be founded...

a different topic :-)

i suppose... unmaintained should have patches and very small, concise
changes to poorly maintained, and maybe even _very_ few to regularly
maintained. yet, most security related alerts are for higher profile
applications; a more immediate response i would think?

i simply don't want to see a collective effort to preempt upstream; i
prefer to manually digress from vanilla, and i'm probably a minority.



Not really. We do like vanilla software and aim for that in our repos.
But it not an unbreakable rule.


What I would like to see one day is a header on all patches detailing
where they come from and what they do. Something like in Debian of LFS.


Allan
 
Old 06-22-2010, 08:16 AM
Caleb Cushing
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
> 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).
>

how 'bout things upstream doesn't take care of like pam.d policies...
I seem to recall there being a request for a pam policy for login
managers... as a result of my pointing out that even if your shell is
false you can login graphically.
--
Caleb Cushing

http://xenoterracide.blogspot.com
 

Thread Tools




All times are GMT. The time now is 10:05 AM.

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