[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150126055823.GM13509@openwall.com>
Date: Mon, 26 Jan 2015 08:58:23 +0300
From: "(GalaxyMaster)" <galaxy@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: new code reviews
Solar,
On Mon, Jan 12, 2015 at 03:41:26AM +0300, Solar Designer wrote:
> What reviews have you made of the new/updated upstream code introduced
> with your mid-2014 commits?
It would be quite a lengthy response if I try to address each and every
package I updated. Moreover, it was half an year ago, so my memory has
faded since then.
I think our progress in keeping Owl up to date is suffering from not
separating two distinctive tasks: packaging and code review. I'm not
very good at code reviews (you and ldv@ are much better at it), but I'm
quite good at packaging. My idea is that if one supplies updates to
packages in a consistent way it would be much easier to focus on the
code reviews by those who have the proper skills.
Right now, the approach is that whoever updates a package is also taking
the responsibility of reviewing the code. This makes the update a long,
time-consuming process. Especially, if the one who does the packaging
lacks experience in source code audits. My approach to packaging is
quite simple:
* update the source package;
* re-apply any relevant patches from the previous package in Owl;
* check other distros for patches applied to the updated version and
cherry pick ones that relevant to our platforms.
My understanding is that the described approach leaves us with a package
that does not require a full-blown code review, but a smaller,
incremental one between 'rpmbuild -bp <old_package>' and 'rpmbuild -bp
<new_package>' source trees, which should be quicker.
> In CONCEPTS, we claim:
[skipped]
> Arguably, the code you added/updated isn't "important" enough to require
> proactive review per these terms.
>
> I am especially concerned about nss and nspr. Why does the new rpm need
> them?
>From RPM's INSTALL:
===
The NSS >= 3.12 library for encryption, and NSPR library which NSS uses.
===
Additionally, although INSTALL does not mention it, there is an option
to use libbeecrypt (http://sourceforge.net/projects/beecrypt/) instead
of Mozilla's NSS. However, I'm not sure how long RPM will support this
since everybody else are building RPM with NSS (as far as I know).
> What other Owl-relevant software needs them (so that we'd want to
> keep them available for use by other than rpm)?
As far as I know no other packages in Owl depend on NSPR/NSS, however, I
recall that there are a couple of packages on my hosting server that use
NSPR (I can't quickly recall their names, unfortunately).
> Speaking of rpm's signature checking, if it requires this sort of crap
> now I'd say that maybe we better drop/exclude its signature checking
> support (which we don't use ourselves anyway, using mtree instead).
I'm OK with cutting it out, however, I foresee it as quite a big task to
do and I don't have enough time to do it right now. Is it worth it? If
we limit the use of NSS to RPM only the risk should not be that high
(and if somebody does something like "rpm -Uvh
http://somehost/package.rpm" as root, they are in trouble anyway).
> Being able to check signatures of other distros' packages on Owl before
> possibly installing them on an Owl system is nice... but maybe not nice
> enough for us to bite that bullet.
Once again, I'm a good packager and can supply updates. I understand
and can fix issues with the source code, but I'm not ready to embark on
crusade of shaping the functionality to meet our security demands. I'm
lacking proper skills and time for that. I can help (if guided), I can
assist, but I cannot take it over completely. The reason behind
updating RPM was that I'm slowly building an environment where I can use
yum/dnf with Owl. Looking at Fedora Core and the development of
rpm/yum/dnf I realise that achieving my goal will be much harder with
the outdated RPM, so I started to push newer RPM to Owl. Also, if you
look at the activity http://rpm.org/wiki/News (and rpm's git repository)
it seems that there is a trend of cleaning up RPM's codebase. It's the
trend I like and I think we may benefit from these efforts too.
If you want to shape the package functionality in any way, just speak up
and I'll do whatever is required to bring it to the desired state (if
time permits).
--
(GM)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
