GPG signatures for source validation

[NicoHood]

Hey Giuseppe, I am NicoHood, maintainer of some ArchLinux packages. My roommate @Gituser789 is using your software for years now and super happy about that. He asked me to add cherrytree to the official ArchLinux repositories. I am happy to do that, if the sources are PGP signed. Here is a short description why:

As we all know, today more than ever before, it is crucial to be able to trust our computing environments. One of the main difficulties that package maintainers of GNU/Linux distributions face, is the difficulty to verify the authenticity and the integrity of the source code. With GPG signatures it is possible for packagers to verify source code releases quickly and easily.

In order to securely package your software I am kindly requesting GPG signatures for the source tarballs. If you are not yet familiar with secure source code signing I recommend using GPGit which automates the process of secure source code signing and also has a quick start guide on GPG for learning how to use it manually.

If you have any questions, please let me know :-)

[giuspen]

Hi Nico that's fine I'll try and gpg sign from the next release 0.99.26

[NicoHood]

Nice!

Would you mind having a look at the current AUR PKGBUILD? I'd adapt this one, but I got a few questions:

• Can you please have a look at the used build flags, if those are correct?
• What about the uchardet dependency? This is not listed in the readme, I guess that could be fixed? Or is it obsolete now?
• I am curios: Why is this package half c++ and half python?
• If you have any important change in the build process in the future it would be nice if you could email me or reply to this topic :-)

[giuspen]

• Uchardet is correct, I have to update the readme
• python-lxml is no longer a build dependency (but python3 is necessary to build only)
• -DBUILD_TESTING:BOOL=OFF you need to build/run the unit tests on a headless server without xvfb
• the project used to be Pygtk2 now Gtkmm3

[NicoHood]

Thanks a lot!

I tried to enable the unit tests (very useful), however I get the error:

CMake Error at tests/CMakeLists.txt:4 (add_subdirectory):
  The source directory

    /build/cherrytree/src/cherrytree-0.99.25/tests/googletest

  does not contain a CMakeLists.txt file.

I guess I need to download some additional files, do you have any hint? The built is run in a chroot, so it should be considered "headless"

[giuspen]

If you download the .tar.xz from giuspen.com there are the googletest source files but if you download a tag from GitHub you won't find it because it's a git submodule

[giuspen]

0.99.26 will be GPG signed, so closing this now

[NicoHood]

Thanks for adding signatures!

The information on the download page is a bit confusing and the signature should be rather a detached signature:

gpg2 --digest-algo SHA512 --armor --detach-sign cherrytree.tar.xz

# And verify with:
gpg2 --verify cherrytree.tar.xz.asc

That is the common usage, also supported by the packaging tools

The key does not expire, is that correct?

[giuspen]

I'm no expert with the gpg signing, I've been trying to reuse the key I have setup for launchpad / giuspen ppa but I'm not sure I made it right, let me try again with your suggestions

[NicoHood]

Sure no problem. I am happy to help. GPG is super annoying, but its the only tool we have to secure sources like that...

Also, you could enable git commit signing: https://github.com/NicoHood/gpgit#32-enable-commit-signing

Maybe gpgit is worth a look, as it explains a secure and basic gpg setup in short, but also gives you the tool to automate the whole thing. (Spoiler: I've also written that to help maintainers like you)

[giuspen]

Thanks Nico, I updated the script and the download page, with the link to the .asc file. I will have a look to your tool but I quite like to have control of the commands, I didn't know about the detached signature and I'm glad I now know :)

[merkys]

By the way, where can I find the GPG public key to verify the signature?

[giuspen]

It's described at https://www.giuspen.com/cherrytree/#downl

[merkys]

Found it, thanks!

[NicoHood]

I've noticed that there are some external libraries in https://github.com/giuspen/cherrytree/tree/master/src

Two of them I've found in the arch repos: https://archlinux.org/packages/community/x86_64/spdlog/ https://archlinux.org/packages/extra/x86_64/p7zip/

Is it possible to also link them as a shared library? You are more familiar with the build process :-)

Edit: The GPG signatures now work fine! Also many thanks to morgenstern from the AUR for helping me out with the unit tests!

[merkys]

@NicoHood I've tried building with the shared library of spdlog 1.5.0, but the build failed. Most likely due to incompatible version.

[giuspen]

p7zip is strongly customised, about spdlog it was not me to add it so I don't know yet if it's easy to use an external version nor the reason to bundle it, I'll have a look

[NicoHood]

Is there a specific reason why using -O3? I am asking because of:

Using -O3 does not guarantee that the software will perform better, and sometimes it can even slow down the program. It can also break software in some situations. There is a good reason why the Arch Linux developers choose -O2 as the target optimization level and we should stick with it. Unless you know exactly what you're doing, or if upstream explicitly tells or implies that -O3 is needed, we should avoid using it in our packages.

https://wiki.archlinux.org/index.php/CMake_package_guidelines#Notes_about_-O3

[giuspen]

-O2 is OK for me.

[giuspen]

spdlog will no longer be bundled in the sources from next version 0.99.28

[merkys]

-O3 also breaks builds on Debian unstable, but -O2 is fine.

[cmorgenstern]

I see from this issue that access to giuspen.com is restricted by IP address.

As the Arch Linux AUR PKGBUILD uses the sources made available from giuspen.com since that is where the GPG signatures are present, could you please ensure that new releases on GitHub have the GPG signature included as well? That way I can safely switch the sources over to GitHub and end-users will not run into downloading issues.

[giuspen]

There are no IP restrictions on giuspen.com

[cmorgenstern]

OK. If GitHub is supposed to be the primary place to get the code, though, then would you mind making the GPG signatures for the source code available for new releases on GitHub as well?

[giuspen]

The thing is I'm not releasing at all on GitHub, just tagging the commit corresponding to the release

[giuspen]

If it's possible to host tarballs on GitHub for free surely I can put those there with the signatures, I wasn't aware an FTP like space was available

[cmorgenstern]

Thank you, that would be much appreciated.

Alternatively you could look at also doing a GitHub release for each tagged commit, which would allow you to add a detached signature.

[NicoHood]

One more question: Is it possible to run the checks without building the software twice? If you look at the current PKGBUILD, you can see, that we are building the software twice. This is not that critical issue, however it would be nicer and cleaner: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cherrytree#n45

2nd question: spdlog is currently only required as build dependency. I assume that it is not linked shared then, cause a shared lib is a required runtime dependency. Do we need some additional flag to link it as shared?

[giuspen]

@NicoHood I don't see the need to run the build twice, that's not what I do and I don't understand why you need to do it. If you build on server without xorg you don't build the unit tests (or use xvfb-run trick), otherwise you do. If you build also the unit tests that's not a problem, those are not in the make install target so won't be in the package anyway.

Spdlog is not only for the build (unless headers only version).

@cmorgenstern unfortunately I haven't found a way to upload files to GitHub / have a small FTP like space

[NicoHood]

In PKGBUILDs we want to separate the build from the check (unit tests etc). And the only way we found yet was to run the tests like that. To you have any suggestions on how to improve this?

Spdlog is not a runtime dependency, as cherrytree runs without it being installed and also namcap (the archlinux tool for validation packages) does not report any missing dependency. So you might want to check that again, I am not sure.

About github: Just go to releases and create a new release for the corresponding git tag: https://github.com/giuspen/cherrytree/releases

[giuspen]

Thanks for the tip about GitHub! About spdlog must be header only, there's no other explanation because it is used in runtime. About the unit tests, the only thing I can do is to help you in not having them run automatically as you build them so you can run those separately at wish. Would that help you?

[cmorgenstern]

@giuspen yes please, I think that would work well. That way, the check() function in the PKGBUILD can just execute the compiled unit tests. @NicoHood any comment on that proposal?

[NicoHood]

That sounds good (unit tests). About spdlog... I am not sure why this happens.

[cmorgenstern]

@giuspen is there a specific function in cherrytree that requires spdlog? If you can give me steps to re-create using that function, then I can test whether the absence of spdlog would cause the application to fault.

[giuspen]

Well there are calls to spdlog everywhere, all the debug prints that you see if you run from a terminal

[giuspen]

Ok if you add the cmake argument -DAUTO_RUN_TESTING="" the unit tests won't be automatically run

[NicoHood]

Nice! And how to run them manually afterwards?

[giuspen]

The binary test file is build/run_tests, you simply run it to execute the tests

[cmorgenstern]

Thanks @giuspen - this really speeds up the compile time for Arch Linux builds.

@NicoHood here's a PKGBUILD that uses the new method of building and running the tests separately. Feel free to integrate the changes into the official package as I have already done with the AUR cherrytree-git PKGBUILD.

[NicoHood]

Nice! Now the only thing left is why spdlog is not linked shared yet...