Hello again,
intrigeri wrote:
> Hi s7r & list,
>
> s7r:
>> intrigeri wrote:
>> That was a great idea, got countless appreciations for that and also,
>> based on the feedback I receive and discussions the feature is *very*
>> popular in Tails. We should definitely not drop it.
>
> To be clear, the email that started this thread was neither a proposal
> (nor a threat!) to drop it: as long as Electrum keeps working for
> basic Bitcoin usage without needing extra work, I'm happy to keep it
> around. Now, once we've released WIP improvements to our Additional
> Software Packages feature, Electrum is definitely on the list of
> packages that we should consider making opt-in; but I expect we'll
> keep the integration bits (e.g. pre-configuration & persistence
> feature) anyway.
>
All clear and noted. Thanks.
>> However, I don't think we should upgrade the package after exactly each
>> and every Electrum release, unless it's something critical or stuff like
>> this.
>
> Fully agreed, I don't think we should set the bar this high (even if
> the Electrum project had a very trustworthy QA process and brand new
> releases introduced regressions extremely rarely).
>
Confirm.
>> At this moment for example we MUST upgrade to Electrum 3.x because it
>> includes a major change, that is not compatible with older versions
>> (SegWit transactions -- this change was quite controversial and took a
>> lot of time, but fortunately it's locked in permanently at this moment).
>> One user running something prior 3.x will not be able to have new native
>> SegWit addresses and benefit of the reduced fees, plus some payers or
>> payees might require payment to a native SegWit address, without
>> offering a legacy address.
>
> Good to know, I was not aware of it so I'm glad I've raised this topic
> here and you could answer it! :)
>
>> I am quite aware of this ever since first 3.x release, it's being worked
>> on (Tristan Seligmann from Debian is a mega help) but it takes slightly
>> longer than usual because among with SegWit, in 3.x Electrum was also
>> re-written in Python3 which is not in stable. Something will be soon
>> uploaded to unstable, and then I was planning to open a ticket when it's
>> in testing to include it in the next Tails release.
>
> It's excellent that you're on top of this. Please consider creating
> this ticket now (and explain there what the next steps are & what we
> are waiting for), so that our Help Desk can redirect users who request
> this somewhere.
>
Done. I explained there what we are waiting for:
https://labs.riseup.net/code/issues/15022
> Shall we add you as a watcher for all tickets related to Electrum?
>
Yes, please. I should be able to provide relevant information and
clarifications in such cases.
>>> If someone here particularly cares about Electrum support in Tails,
>>> here's what you can do:
>>>
>>> - wrt. bringing new features to Tails: get involved in the Debian
>>> package maintenance and maintain Electrum in stable backports
>>> (currently: stretch-backports)
>
>> I will check the policy for stable backports to see, but I think it
>> might be easier to use *testing* for this package particularly because
>> this is just how the cryptocurrency world is, it might provide updates
>> faster than we can have them in the stable repo and also sync these
>> timings with Tails releases. In testing we can have them in 7 days,
>> which would be good for us.
>
> A backport can be uploaded (and all such uploads will be automatically
> accepted once a first one has been manually accepted to a given suite)
> as soon as the package reaches Debian testing, so installing from
> backports does not add any relevant delay, except in the rare case
> when the timing of the migration to testing conflicts in the worst
> possible way with the Tails freeze schedule.
>
> Installing from Debian testing can definitely be a sane short-term
> option *but* this is brittle and can't be relied upon on the long
> term: at some point it's likely that the package from testing becomes
> uninstallable on stable due to new/updated versioned dependencies.
> So we install packages from testing only when we can be fully certain
> that whenever this happens, someone starts maintaining a backport
> immediately. I would recommend they start doing it now.
>
Ok. Will work on this.
>>> - wrt. fixing bugs (if no good backport is actively maintained): get
>>> involved in the Debian package maintenance and fix in Debian
>>> *stable* any important bugs and issues that make the version
>>> included in there irrelevant/obsolete
>>>
>
>> If we could use the testing repo for this, things could be solved easier
>> (I hope).
>
> Yes, if we install from backports or from testing, technically *we*
> don't have to care about the version that's in Debian stable (it's the
> Debian maintainer's responsibility to do so).
>>> - in any case:
>>> * track upstream development closely, in order to pick the best
>>> versions for Debian unstable/testing and stable backports,
>>> or to identify bugs that shall be fixed in Debian stable;
>>> * act as a liaison with Tails developers to let us know when we
>>> should upgrade to which version (e.g. "there's now
>>> a well-maintained backport, please ship it").
>
>> I can take this. I am tracking, testing, providing feedback and
>> suggestions upstream, and also track and use Tails so I can easily do it.
>
> Perfect!
>
>> Since then, there were few other releases but I did not open tickets
>> because the version we shipped was/is working. It may not have all the
>> features of the last release, but it is not useless, it is working and
>> nothing serious or security related needed to be addressed. From my
>> point of view, in a system like Tails which takes care of other things,
>> upgrading for minor features is both impractical and not necessary.
>
> Fully agreed.
>
>> We can just sync on every Tails release with the Electrum version in
>> testing, but this requires testing and review (on last upgrade the
>> config file format changed slightly which was affecting users with
>> persistence enabled and were still having the old config file on disk).
>
> Ideally Electrum upstream would sensibly handle such config
> updates itself. But sometimes it's not possible, or nobody cares
> enough to implement it, so:
>
> - We occasionally add automatic migration code for pre-existing
> persistent config e.g.
> https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/sbin/live-persist#n131
>
> - Failing that, we document in the Tails release notes what users
> need to do in order to migrate their config.
>
Plausible. Will take care of this.
>> Either way, let's keep it. Let me know what you think.
>
> I feel relieved to see you commit to all the above!
>
Sure.
> Are you also interested in maintaining the Electrum integration into
> Tails (e.g. taking care of whatever needs to be done on incompatible
> config updates and similar Tails-specific glue)? If you want to commit
> to this, at some point we should probably add you as the point of
> contact for Electrum matters on
> https://tails.boum.org/contribute/#mentors :)
>
I can do that. Been replying to emails with questions for this for some
time now. Just for the record, I don't have commit access upstream, but
I think I could fix Tails-specific needs because it's a big user base
that uses this additional software package and also because the main
developer and entire upstream community takes security and privacy very
very seriously, just like we do, that is why I support this being
included in Tails.
