MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003275Doomseeker[All Projects] Suggestionpublic2017-09-25 16:422018-10-27 22:53
ReporterWubTheCaptain 
Assigned ToBlzut3 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version1.2Fixed in Version1.2 
Summary0003275: Sign tarball releases with OpenPGP keys
DescriptionPlease sign tarball releases of Doomseeker, its plugins and libwadseeker with OpenPGP keys. This is used for cryptographic integrity verification.

For an additional benefit, this would prevent a malicious actor from replacing the downloads with malicious versions undetected without also possessing the private key to sign the releases.

Debian also makes a recommendation to sign tarballs in their Upstream Guide.
Steps To ReproduceSignature files should appear at:'https://doomseeker.drdteam.org/files/ [^]'
Additional Information'https://wiki.debian.org/UpstreamGuide#Tarballs [^]'

OpenPGP signatures can be created with free software (GnuPG):'https://gnupg.org/ [^]'
TagsNo tags attached.
Relationships
child of 0003279acknowledged  List of Debian issues (misc/non-policy) 
child of 0003483closed Blzut3 Doomseeker 1.2 release 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-09-25 16:42WubTheCaptainNew Issue
2017-09-25 17:37ZalewaRelationship addedchild of 0003246
2017-09-27 22:32WubTheCaptainRelationship addedchild of 0003279
2017-09-27 22:32WubTheCaptainRelationship deletedchild of 0003246
2017-09-27 22:55WubTheCaptainNote Added: 0018406
2017-09-27 22:56WubTheCaptainNote Edited: 0018406bug_revision_view_page.php?bugnote_id=18406#r11014
2017-09-27 22:56WubTheCaptainNote Edited: 0018406bug_revision_view_page.php?bugnote_id=18406#r11015
2017-09-27 23:03WubTheCaptainNote Edited: 0018406bug_revision_view_page.php?bugnote_id=18406#r11016
2018-09-01 12:16WubTheCaptainNote Added: 0019474
2018-09-24 01:14Blzut3Target Version => 1.2
2018-09-24 01:15Blzut3Assigned To => Blzut3
2018-09-24 01:15Blzut3Statusnew => assigned
2018-09-24 01:15Blzut3Relationship addedrelated to 0003483
2018-09-24 02:05Blzut3Note Added: 0019699
2018-09-24 02:05Blzut3Statusassigned => needs review
2018-10-01 03:34WubTheCaptainStatusneeds review => needs testing
2018-10-01 04:05WubTheCaptainRelationship replacedchild of 0003483
2018-10-06 09:02WubTheCaptainPriorityhigh => normal
2018-10-08 11:18WubTheCaptainNote Added: 0020014
2018-10-08 20:58Blzut3Note Added: 0020032
2018-10-08 21:54WubTheCaptainNote Added: 0020041
2018-10-08 22:36WubTheCaptainNote Added: 0020043
2018-10-08 22:41WubTheCaptainNote Added: 0020044
2018-10-08 23:28Blzut3Note Added: 0020045
2018-10-09 10:20WubTheCaptainNote Edited: 0020044bug_revision_view_page.php?bugnote_id=20044#r12207
2018-10-09 10:24WubTheCaptainNote Added: 0020049
2018-10-09 10:24WubTheCaptainStatusneeds testing => resolved
2018-10-09 10:24WubTheCaptainFixed in Version => 1.2
2018-10-09 10:24WubTheCaptainResolutionopen => fixed
2018-10-09 10:25WubTheCaptainNote Edited: 0020049bug_revision_view_page.php?bugnote_id=20049#r12209
2018-10-27 22:53WubTheCaptainStatusresolved => closed

Notes
(0018406)
WubTheCaptain   
2017-09-27 22:55   
(edited on: 2017-09-27 23:03)
From a Debian maintainer's perspective, OpenPGP signatures are optionally used for quality control and maintenance with the uscan utility. Emphasis that this is completely optional to both the software and Debian maintainer. (Debian Policy Manual v4.1.0.0, section 4.11.)
(0019474)
WubTheCaptain   
2018-09-01 12:16   
Can this be a target for 1.2? I'd like to know if 0003483 should be related to this ticket.
(0019699)
Blzut3   
2018-09-24 02:05   
Captured generation of signatures in'https://bitbucket.org/Doomseeker/doomseeker/commits/9c0b8812f164a752f2cbbff7c6c68394c704355d [^]'
(0020014)
WubTheCaptain   
2018-10-08 11:18   
I'm not sure how one is supposed to test this.
(0020032)
Blzut3   
2018-10-08 20:58   
Pretty much why I only tagged it as needs review. If the script spits out signature files in the format you expect (obviously with your key instead of mine) then that's enough to say this ticket is resolved.
(0020041)
WubTheCaptain   
2018-10-08 21:54   
I mean, the script itself doesn't provide any description of usage. I also can't read bash well, my expertise goes to POSIX sh scripts. What the heck is "Arg:7" and where/what are the args 3–6?
(0020043)
WubTheCaptain   
2018-10-08 22:36   
It took me a lot of guesswork from reading the lines the usage is `./makesourcepackages.sh --sign=$fingerprint`, where $fingerprint is one of GnuPG key fingerprints. This is counter-intuitive in many ways (contradicting POSIX?).

Because I can't read the script with immediate clarity anyway, it'd not pass my code review but I'd kindly request a rewrite. I'm not going to do that myself, not yet at least.

I still have no idea how the script works. But it does.
(0020044)
WubTheCaptain   
2018-10-08 22:41   
(edited on: 2018-10-09 10:20)
Quote from WubTheCaptain
I still have no idea how the script works. But it does.


Badly, if I may add. Doing the slow process of getting stuff ready before attempting signing, only to possibly error and bail out late that the key was incorrect (e.g., expired). Frustrated me at least.
(0020045)
Blzut3   
2018-10-08 23:28   
I have no idea how you can't follow that script. I don't use gpg much so honestly I don't know anything about selecting keys besides that it's done with -u. But I only have one key so I just use `--sign` and be done with it. I wanted to have it show the key it was going to use, but I couldn't figure out how to have gpg just give the fingerprint of the default key. (I can easily find how to list all keys and how to set the default, but how to see the default I gave up on.)

"${Arg:7}" is a substring. See bash man page.

Anyways the first thing it does (line 117) is extract the versions from the CMake files. This is done by running CMake in script mode including the version definitions and having it print out the result. Nothing fancy here just using the correct tool to parse the file. Unfortunately CMake always writes to stderr so that's a little ugly. Once it has those it strips the beta tag off it using bash suffix removal of ~ and everything following.

Next we use Mercurial to create a directory with the committed code ready for archiving. This prevents working copy changes from polluting the release.

Heading into the create_vcs_info call: A build directory is setup and the revesion_check target is built and run in order to generate the gitinfo.h. This works since update revision modifies the source tree which previously caused builds to be non-reproducible. But since we build it here it's baked into the source tarball and not touched when the end user builds the release.

We are now done with the magic and head into the most straight forward code ever: Creating two tar balls. I use tar piped into xz since I'm too lazy to figure out how to have tar do it with maximum compression. Plus it's more portable like that I guess.

Lastly, if the --sign option was given sign_archive will generate gpg signatures. If this fails then it's the same as if you called no-sign except that you'll get an error in the return code.

So which part of this was hard to read? "I don't understand the language you wrote it in" is not a valid reason to rewrite.
(0020049)
WubTheCaptain   
2018-10-09 10:24   
(edited on: 2018-10-09 10:25)
It is all so unconventional and non-portable, that is all.