Here is a rudimentary package for annealmail the codecrypt plugin for Thunderbird. The Debian folder was generated by debhelper and dh_make, cruft cleaned up manually using pointers from lintian and pushed to git. Building was not tested again:
Still finding my way around git so please be gentle.
I would like to be able to set things to rebase off of upstream changes to benefit from changes straight away.
You don’t actually commit to Debian branch. Therefore, do once:
git branch -D debian
git push yourgithubusername :debian
Then.
git remote add adre https://github.com/adrelanos/annealmail-2.0.git
git fetch adre
git checkout adre/debian
Create local debian branch.
git branch debian
Checkout.
git checkout debian
Not sure that works, I use git so much that I can make sense of any output and error messages but I guess that’s it.
One commit on top by me.
https://github.com/adrelanos/annealmail-2.0/tree/debian
Cannot test to build it for security reasons. I don’t speak the language. Cannot say if there is nothing malicious in the source code. Cannot even gpg verify the code by upstream since it is not signed (issue referenced above). Even if I did speak the language or if it is simple, it is just too much to review.
debian/copyright needs fixing. Debian will be adamant about this. Some examples:
bindp debian/copyright
corridor debian/copyright
whonix-ws-kde-desktop-conf debian/copyright
Also lintian --pedantic will complain if debian/copyright is not ok.
${shlibs:Depends},
${misc:Depends},
${xpi:Depends},
Recommends:
pinentry-x11,
${xpi:Recommends},
Provides:
${xpi:Provides},
Enhances:
${xpi:Enhances},
Breaks:
${xpi:Breaks},
Any ones that can be removed without lintian complaining? If lintian complains, keep, otherwise, please remove.
Will these be actually substituted with something? ${xpi:Breaks} etc are variables substituted by debheper. When you unpack the created .deb. package, look at that debian/control (and others files) for actual result.
Is it still worth working on this with this fact in mind? One might argue that there is a high possibility that not every line of every Debian package was ever reviewed. Reproducible builds don’t change this though they guarantee that no one put any special Easter eggs in the binaries.
https://github.com/annealmail/annealmail/issues/11#issuecomment-367810918
this project hasn’t been updated for a while. I doubt it will get updated in the near future
Basically, project is dead/abandoned, shouldn’t use?
Yes, since it is a collaborative effort. Perhaps can be mentioned here: https://github.com/annealmail/annealmail/issues/10 Perhaps someone else will help out.
I wonder about that one. Could you please discuss all of this with the debian-mentors mailing list or on their IRC?
True. Reproducible only helps us to confirm that the source code that one claimed to have used to create a binary was really the source code claimed to have been used. The actually source code still needs to be manually audited and no automation for that is conceivable at the moment.
As per https://github.com/exaexa/codecrypt/issues/17#issuecomment-269320906… Perhaps if packaging/building is done, Debian privacy applications team might be interested to help out? https://alioth.debian.org/projects/pkg-privacy/
Depends on what task seems too daunting to them. If part of the work is done, perhaps they’d have some insight for above question and/or be willing to help?
I was mentally looking past this because I thought “Its based on Enigmail which is pretty sturdy” - except that some pretty serious problems were discovered and fixed in a security audit sponsored by Mozilla and Posteo at the end of last year. Changes that are almost definitely not included in annealmail becuase its now a couple of years old and not being rebased on more recent versions or updated.
I’m thinking of doing my duty and notifying annealmail’s author anyway though likely its not going to change anything.
Given these developments I don’t think we should waste any more effort on packaging. As a general rule, security software should be extremely well maintained to be considered for inclusion by default.