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.
>
> It is not about disc space (although the space required for a complete
> Debian archive across all architectures and suites is not an
> inconsiderable factor). It is about duplicated workload.
>
>> The answer for such cases is "merge your patches upstream" - yes, but if
>> upstream isn't interested?
>
> Then create a new upstream which can take the patches and package the
> code *ONCE*.
>
>> 2) The MATE Desktop
>>
>> They didn't make their way into Debian, also because of the "no code
>> duplication policy".
>
> Same reasons - there have been and will continue to be security bugs in
> packages like cairo which underpin GNOME2. Duplicating code is not the
> answer.
>
>> There are other applications, which didn't make into Debian repository,
>> because of that policy...
>
> Good. Debian is better off without more embedded code copies and needs
> to continue pushing against embedded code in existing packages.
>
>> In conclusion...
>>
>> I think the correct question to ask isn't "does it duplicate code?", but
>> "won't it break something?"
>
> All duplicated / embedded code breaks everything else which embeds the
> same code because all copies need to be fixed at once.
>
> Every package which embeds code available in a separate package is
> buggy by definition - it is broken by design.
>
>> , "is it well maintained?"
>
> By whom? Every time code is duplicated, you also duplicate the number
> of people who need to do something to update that code.
>
>> , "is upstream
>> generally ready? (not too many bugs)".
>
> Which upstream? Every upstream embedding the code will have their own
> release schedules, timelines and priorities.
>
> Single codebase, single upstream should be the objective.
I get your point. Generally, I understand the goal of no code
duplication. Sometimes it just doesn't work if upstream and alternative
upstream are too different.
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.
A big threat for Tor Browser users is, that an adversary compromises a
SSL certificate authority and spreads infected copies. Proper gpg
verification is beyond what most mortal users are capable off (just look
at the download statistics or try to explain that someone not into
computers), especially if you want to do it right with the trust path.
That threat is real, an SSL CA compromise already happened.
It is also my understanding, that security isn't a top priority for
Debian. 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.) For an
adversary, it's an effective way to target the build machines or the
people who administrate those build machines. And no, I doubt that
people running the binary packages in a debugger all day to see if they
have been back doored. That may be possible for some skilled people
after suspicion, but won't happen for the majority of package updates.
Deterministic builds are the answer, but I don't see anyone care or
talking about.
In the Tor Browser case, alternative upstream (The Tor Project) could
also be packager at he same time. I'd prefer, if the question, whether
the alternative upstream really lags behind original upstream with
security fixes or does a good job at this would be raised instead of
assuming that they automatically lag behind. "Tor has a staff of 14 paid
developers [...]" [1] (Ok, not all working on Tor Browser.) I think it
would be worth giving it a real chance.
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.
And if the Tor Browser download (torbrowser-launcher) makes it into
Debian, that will result in the same practical consequences. Users will
have code duplication on their system. The torbrowser-launcher doesn't
solve the code duplication security issues, it only work around the
policy. - Is that really necessary?
As for porting, they currently have Linux 686, Linux x86_64, Win 32, osx
i386 and osx x86_64 builds. Not sure if their linux builds also work on
BSD. I am not much into porting to other platforms. I doubt that adding
Tor Browser to Debian repository would make it available to fewer
platforms than right now. So blocking it for this reason is only a
policy thing as well.
[1]
https://www.torproject.org/about/jobs.html.en
