On Tue, 26 Feb 2013 11:53:31 +0000
adrelanos <adrelanos@???> wrote:
> Neil Williams:
> > On Mon, 25 Feb 2013 21:09:19 +0000
> > adrelanos <adrelanos@???> wrote:
> >
> >> 1) Tor Browser
> >>
> >> It can't make it's way into Debian due to "no code duplication policy".
> >
> > i.e. security support and porting ability.
> >
> > Every time a codebase gets duplicated amongst a variety of packages,
> > there are inevitable problems:
> >
> > 0: bugs in one version take forever to get fixed in all versions
> >
> > 1: security fixes in the embedded code need to be applied across many
> > packages instead of one. As security support this may need to be done
> > quickly and is therefore best done in a single package not dozens.
> >
> > 2: porting packages embedding that code becomes more difficult
> > because, again, changes need to be pushed through all copies, each of
> > which have their own build systems / patch systems / compatibility
> > issues. You cannot generally just copy the one patch into each package,
> > each one has to fit into the rest of the packaging and be tested.
> >
> > Embedding code within packages *makes more work for everyone*. It is a
> > *bad* thing to do.
> My point is, in this case, what you propose, is only more secure in
> theory, but not for the users who are actually using Tor Browser on Debian.
Not Debian's problem. There are other browsers.
> It is also my understanding, that security isn't a top priority for
> Debian.
Then your understanding is wrong.
> Not judging my reading the policy, but my looking on which
> security aspects people focus on. As far I understand, there is no
> effective way to verify, that a binary package was build from the
> proclaimed source code - not back doored. (By effective, I mean to
> easily rebuild it and to come up with the same check sum.)
Check the checksums from the build log against the checksums of the
actual packages which are then GPG signed in the repository Release
files.
Check the checksum of the .dsc claimed in the same GPG signed changes
file as lists the checksum of the prepared binaries. (.changes files
are available via the PTS.)
Check the contents of a rebuild using Debian tools like debdiff -
binary and source comparison. Individual binary packages contain
md5sums for all files contained within.
The checksums of the actual .debs can vary according to changes outside
the package (build-dependencies etc.) but there is always a trail from
the signed source package checksum to the binary packages built from
that source and that trail is always checksum complete and GPG signed.
> In conclusion, from an outsider perspective, Debian users who are using
> Tor Browser are in reality currently less secure, because they have to
> download it from the torproject.org website manually and could be more
> secure, if they could download and update it through the Debian mechanism.
Correct. That involves removing the embedded code. No ifs, no buts, no
exclusions. Do it properly and work willingly with the security team
and the porters or just don't bother.
> As for porting, they currently have Linux 686, Linux x86_64, Win 32, osx
> i386 and osx x86_64 builds.
So no armel, armhf, arm64, mips, mipsel, sparc, powerpc let alone the
BSD and Hurd ports. Fix the codebase, make it fully portable or there
is no point considering inclusion in Debian.
> Not sure if their linux builds also work on
> BSD. I am not much into porting to other platforms.
Tough. Porting is at least as important to Debian as security and there
is a new Debian port roughly every 12 months. If you want to work with
Debian, you *must* work will porters, continually. If you want to
introduce a security risk into Debian - and all browsers are security
risks by definition - then you must also work with the security team,
continually.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
