Hi Scott, Thanks for the relevant links to the discussion that I wasn't aware of.
On Thu, 9 Jan 2014 10:02:37 Scott Howard wrote:
> If you disagree, I'd be interested in hearing why.
Mostly my decision is based on our policy. I'm convinced that
discouraging linking to private libraries is one of the best practices
that we have in Debian. No only it benefit security but also it helps
to maintain coherent up-to-date distribution, encourage communication
and cooperation between maintainers as well as compartmentalise
development without unnecessary duplication.
There are some cases when we have to use bundled library due to local
modifications: for instance we can't use system "libjson-spirit"
because bundled version is different. (I don't know if Bitcoin
developers tried to submit their changes to "libjson-spirit" for
acceptance upstream).
Generally speaking I often find rationale provided by upstreams in
order to justify bundling components to be weak. With the rare
exceptions following our policy is the best practice.
One of the most convincing arguments that I've seen is the following:
http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc
But there are problems:
* We can't ask our users to use upstream-provided binaries.
* Mentioned "unique testing procedures" are not documented in sources
so how can _we_ test?
* It does not make sense to use bundled LevelDB merely because of
"backdor audit". Can't they audit upstream LevelDB release rather
their own copy?
* If using system-wide library makes software fragile it better be
fixed (as well as automatic testing improved to catch possible
causes). Otherwise even using bundled libs won't actually guarantee
integrity or anything.
Basically they are saying somewhat "trust us and beware of any local
modifications".
The above can be taken as the evidence for insufficient post-build
testing which is a weak argument for using bundled software
components.
To support their argument they mention the following incident:
https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
But I fail to see how it applies to our situation. From reading
incident report I realise that network safety do not depend that much
on bundled LevelDB or the whole network would be too fragile for
anybody's confidence. Indeed if problem happened due to disagreement
between BerkeleyDB-based and LevelDB-based Bitcoin software I don't
see how this can support this idea that not using bundled LevelDB can
cause implications for the whole network.
Upstream developers emphasise testing. This is one of my reasons to
use system LevelDB which at least runs post-build tests to ensure that
LevelDB is functioning properly. Bitcoin/Litecoin build system doesn't
do that. System LevelDB is also better tested with all its patches and
build flags simply because it is used by more than one package so
there are more eyes on it and potential problem(s) are more likely to
be reported. As maintainer I may not know whether bundled library is
affected by the same issue or if it would be safe to apply patch to
bundled LevelDB without Bitcoin developer's blessing. Finally the only
authority on LevelDB is LevelDB developers, not Bitcoin devs.
After building new Litecoin version I always let it run for some time
before upload. I reckon if there are any disagreement(s) with network
it would probably at least fail to catch-up with blockchain updates.
I'd be interested to know if there are any additional steps to ensure
its proper functioning.
--
All the best,
Dmitry Smirnov.
---
Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman
signature.asc
Description: This is a digitally signed message part.
