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.