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-22-2010, 08:56 AM
Philipp Überbacher
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

Excerpts from Andres P's message of 2010-06-22 01:53:20 +0200:
> 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

Sure, like any dev will be going through every possible bug tracker,
repo or ask any possible user to find patches for his app.
Don't be ridiculous. If you write a patch that's not distro specific,
then it's your job to get it to upstream,
it's the only way it could possibly work. The beauty of arch
is that the patch you just wrote is most likely against the latest
release, and upstream will likely be happy to get it.
--
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
 
Old 06-22-2010, 03:37 PM
Andres P
 
Default Important notice on the Arch Security Team to the whole Arch Linux community.

On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher
<hollunder@lavabit.com> wrote:
> Sure, like any dev will be going through every possible bug tracker,
> repo or ask any possible user to find patches for his app.
> Don't be ridiculous. If you write a patch that's not distro specific,
> then it's your job to get it to upstream,

So it's not just take the time to write the fix, you also have to make sure
you rebase it every time theres a white space patch.

Let upstream know about your repo and then both can work comfortably...

You're implying that upstream is too important or what have you. What about the
inverse?

> it's the only way it could possibly work. The beauty of arch
> is that the patch you just wrote is most likely against the latest
> release, and upstream will likely be happy to get it.

Ok, the beauty of openbsd is that they're running a BIND version that's been
patched to the point of no recognition. They have confidence in their
skills instead of quitting before giving it a shot.

This arch security news group sounds great. Specially if they intend to sit
down and code.

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

On Tue, Jun 22, 2010 at 10:37 AM, Andres P <aepd87@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher
> <hollunder@lavabit.com> wrote:
>> Sure, like any dev will be going through every possible bug tracker,
>> repo or ask any possible user to find patches for his app.
>> Don't be ridiculous. If you write a patch that's not distro specific,
>> then it's your job to get it to upstream,
>
> So it's not just take the time to write the fix, you also have to make sure
> you rebase it every time theres a white space patch.
>
> Let upstream know about your repo and then both can work comfortably...
>
> You're implying that upstream is too important or what have you. What about the
> inverse?

this is just not how it works. yes, you should rebase if your
following _their_ project; it's one command, if that (you can setup
automatic rebasing when pulling). if you submit patches, you don't
need to re-submit unless your patch was affected by subsequent merges.
they don't want to follow 17 obscure forks and figure out how to
merge the work... really? yes, upstream _is_ more important. if you
must have control, publicly fork the work and go from there. it's not
helping anyone by providing alternative builds in the same name,
confusing users, and annoying authors.

>> it's the only way it could possibly work. The beauty of arch
>> is that the patch you just wrote is most likely against the latest
>> release, and upstream will likely be happy to get it.
>
> Ok, the beauty of openbsd is that they're running a BIND version that's been
> patched to the point of no recognition. They have confidence in their
> skills instead of quitting before giving it a shot.

then in my opinion they aren't running BIND. why aren't they pushing
back to upstream? if they have conflicts in the project's direction:
"publicly fork the work and go from there". it's only fair to the
original authors.

lastly, this:

> This arch security news group sounds great. Specially if they intend to sit
> down and code.

plus:

On Tue, Jun 22, 2010 at 8:37 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
> ..........
> with the addition of providing interim PKGBUILDs
> ..........

is precisely what i _don't_ want to see happening, at all, bad bad
bad. if you want to code, spectacular, learn the app, write code, and
submit to upstream. 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. this
is nothing personal, i just flat out don't trust you :-) or a handful
of volunteers, and would prefer you limit yourselves to more
productive/practical actions like alerts, guides, and communicating
with upstream.

the overwhelming majority of security holes are not from holes in
applications, but holes in deployment methods and careless
administration. script kiddies will hit your server with a list of
known passwords and an assortment of other goodies; _this_ is
noteworthy documentation, an "Arch Security Beginner's Guide", and
annotations to existing guides. the likely-hood of falling prey to a
0-day exploit is far lower.

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.

these 'security repos' work alright for debian and friends because
they use a controlled release schedule; there is no guesswork about
the state of the system. trying to do the same for Arch is aiming
for a rolling release, single-lib moving target; my crystal ball
predicts headaches and worse.

again, maybe i'm a minority here, but i _don't_ find patching
appropriate except in rare occasions where relying on upstream is
either not possible or not practical.

having said all that, i _do_ think it would be cool to have lots of
quality security related docs, an official security RSS feed, and
maybe even output from pacman on packages that have outstanding
security flags on them. use your energies to spread knowledge, let
the pro's handle the nitty gritty.

er, IMO :-)

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

On Tue, Jun 22, 2010 at 2:51 PM, C Anthony Risinger <anthony@extof.me> wrote:
>> Ok, the beauty of openbsd is that they're running a BIND version that's been
>> patched to the point of no recognition. They have confidence in their
>> skills instead of quitting before giving it a shot.
>
> then in my opinion they aren't running BIND. *why aren't they pushing
> back to upstream? *if they have conflicts in the project's direction:
> "publicly fork the work and go from there". *it's only fair to the
> original authors.
>

It doesn't matter if they're not running BIND.

They have a real scenario where they can test functionality. This pipe dream
where every package is kept vanilla for the sake of doing so is called
stagnation.

Tacking on a ls from over there, a pwd from over here, a kernel from
elsewhere... isn't going to help anybody develop an OS into refined product.
It's going to feel like a confused crossdresser of a system.

What's the point of keeping packages completely disintegrated
with its surroundings?

They run patched gcc, perl, ksh... etc. And they happen to be the most secure
widely known bsd. Would that be possible if they catered to this vanilla
fetish? No.

Granted, these guys probably don't have the know-how that openbsd does, but they
gotta start somewhere. What better place than the randomness that is arch?

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

On Tue, Jun 22, 2010 at 6:49 PM, Allan McRae <allan@archlinux.org> wrote:
> 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.

what, did you read that far and give up? dead/non-cooperative/poor
upstreams are not the same as healthy, responsive upstreams. and yes,
they do get fixed pretty quick; i can't imagine your dead upstream or
upstreams that haven't released in years scenario affects too many
applications, what, 1%?... and if it does, then they should either be
removed completely or we should start following appropriate points in
HEAD, because the project is probably obsolete or deprecated, or en
route to such.

i've seen several other external projects trying to address the fact
that Arch moving at breakneck speed, leaving no prisoners, doesn't
work too well for a production machines that can't afford to blindly
upgrade junk or reboot at any moment. if so, then you have poor
change management skills, and probably don't have many clients either.
desktop machines? not important.

in the end, i'm not particularly concerned with how people expend
their energy. i personally think chasing microscopic holes in this or
that is a colossal waste of time when the real security issues
surround the other 99.9%; deployment. there are more pragmatic ways
to safeguard against the known unknown and the unknown unknown. but
alas, i'm bored; to each their own.

C Anthony
 

Thread Tools




All times are GMT. The time now is 04:22 AM.

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