freedomofpress
Simpler rpm build (and/or more legible repo)
- [x] I have searched for duplicates or related issues. [Mildly conceptually related: #837]
Description
In our rpm build, we create a source tarball, but we don't really need one; we don't have a "build" step of the build and we just need to copy files into place.
It's possible to use a subdirectory as a Source instead of using a tarball. (Evidence!). (By extension, we could probably use multiple subdirectories as Source0, Source1, but I don't think we have to make things that complicated).
I propose we reorganize the files in the workstation repo so that all the files intended for the SDW laptop are contained in one directory (eg securedrop-workstation-dom0-config), and inside that directory, are in a tree structure that gives some indication of their final destination on the Qubes machine. (So securedrop-workstation-dom0-config/etc/qubes.policy.d/{31-workstation.policy,32-workstation.policy} for example).
Then our rpm .spec file would have a very simple %install and %files section, possibly even as simple as
%install
cp -a securedrop-workstation-dom0-config/* %{buildroot}/
%files
defattr(755, root, root, 644)
/srv/salt/*
/etc/*
/opt/*
/usr/share/*
but we could also make the %files section a little more legible rather than globbing so aggressively (and/or, if we decide we like installing specific files one at a time, we have that option as well, just showing a dramatic example of what we could do if we wanted).
Good
- our build process would not involve making then unpacking a tarball
- less manual error when needing to update the .spec
- easier to tell at a glance what files are going to be on end user's machine and what won't, and where they'll end up
Bad
- Nested directory structure can be annoying
- Maybe some other downsides I haven't thought of yet? (I'm not including "files in this directory will be provisioned to the workstation" as a downside because that's under our control still)
How will this impact SecureDrop/SecureDrop Workstation users?
Should be no user-facing changes
How would this affect the SecureDrop Workstation threat model?
Should be no threat-model-related impacts
User Stories
As a developer [or as an external contributor, or a community member, or an SDW journo/admin], I want to be able to clearly see which files will end up on an end user's machine by looking at the repo
Overall +1 from me, I like being able to skip the tarball step and also like how this brings us closer to the deb building workflow.
I use a template to create an RPM Spec file.
Because I have multiple specs (55), I generate them based on the readme, including the installation scriptlet etc is gathered this way, I understand your %post is very simple, but I try to avoid multiple mentions of the same code, in case a user wants to install manually instead of using the RPM.
It allows for a very simple %files section. I did not finish the specs building yet, I know there are some things missing so I indicate this for a testing only qube.
If you organize the files in the same hierarchical structure you plan to apply to Dom0, it will be much easier indeed. Example: use find on a dir that has the same dir structure that is going to be applied to dom0, them prefix each line with the RPM macro, be it %{_bindir}, %{_datadir} or even in the %install section for %{_buildroot}. No more manual tracking of files in RPM spec. If you also set the correct mode on the repo, it could be identified to set the mode on installation also if necessary.
I see that https://github.com/freedomofpress/securedrop-workstation/pull/1048 started making it better.
# SPDX-FileCopyrightText: 2023 - 2024 Benjamin Grande M. S. <[email protected]>
#
# SPDX-License-Identifier: AGPL-3.0-or-later
%define file_roots %(./scripts/spec-get.sh dev file_roots)
%define my_name %(./scripts/spec-get.sh dev name)
%define branch %(./scripts/spec-get.sh dev branch)
%define project %(./scripts/spec-get.sh dev project)
%define summary %(./scripts/spec-get.sh dev summary)
%define group %(./scripts/spec-get.sh dev group)
%define vendor %(./scripts/spec-get.sh dev vendor)
%define license_csv %(./scripts/spec-get.sh dev license_csv)
%define license %(./scripts/spec-get.sh dev license)
%define url %(./scripts/spec-get.sh dev url)
%define my_description %(./scripts/spec-get.sh dev description)
## Reproducibility.
%define source_date_epoch_from_changelog 1
%define use_source_date_epoch_as_buildtime 1
%define clamp_mtime_to_source_date_epoch 1
# Changelog is trimmed according to current date, not last date from changelog.
%define _changelog_trimtime 0
%define _changelog_trimage 0
%global _buildhost %{name}
# Python bytecode interferes when updates occur and restart is not done.
%undefine __brp_python_bytecompile
Name: %{project}
Version: 1.0
Release: 1%{?dist}
Summary: %{summary}
Group: %{group}
Vendor: %{vendor}
License: %{license}
URL: %{url}
Source0: %{project}
BuildArch: noarch
Requires: qubes-mgmt-salt
Requires: qubes-mgmt-salt-dom0
Requires: qusal-dotfiles
Requires: qusal-sys-git
Requires: qusal-sys-pgp
Requires: qusal-sys-ssh-agent
Requires: qusal-utils
%description
%{my_description}
%prep
%build
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{file_roots} %{buildroot}%{_defaultlicensedir}/%{project}
mv -v %{project}/LICENSES/* %{buildroot}%{_defaultlicensedir}/%{project}/
rm -rv %{project}/LICENSES
cp -rv %{project} %{buildroot}%{file_roots}/%{my_name}
%check
%pre
%post
if test "$1" = "1"; then
## Install
qubesctl state.apply dev.create
qubesctl --skip-dom0 --targets=tpl-dev state.apply dev.install
qubesctl --skip-dom0 --targets=dvm-dev state.apply dev.configure-dvm
qubesctl --skip-dom0 --targets=dev state.apply dev.configure
elif test "$1" = "2"; then
## Upgrade
true
fi
%preun
if test "$1" = "0"; then
## Uninstall
true
elif test "$1" = "1"; then
## Upgrade
true
fi
%postun
if test "$1" = "0"; then
## Uninstall
true
elif test "$1" = "1"; then
## Upgrade
true
fi
%files
%defattr(-,root,root,-)
%license %{_defaultlicensedir}/%{project}/*
%dir %{file_roots}/%{my_name}
%doc %{file_roots}/%{my_name}/README.md
%exclude %{file_roots}/%{my_name}/README.md
%{file_roots}/%{my_name}/*
%changelog
* Fri Jun 14 2024 Ben Grande <[email protected]> - afcb730
- doc: document usage of qusal TCP proxy
* Thu Jun 13 2024 Ben Grande <[email protected]> - a564b3a
- feat: add TCP proxy for remote hosts
* Mon Mar 18 2024 Ben Grande <[email protected]> - f9ead06
- fix: remove extraneous package repository updates
* Fri Feb 23 2024 Ben Grande <[email protected]> - 5605ec7
- doc: prefix qubesctl with sudo
* Sat Feb 17 2024 Ben Grande <[email protected]> - dbed18d
- feat: Bitcoin Core and Electrum servers and wallet
* Mon Jan 29 2024 Ben Grande <[email protected]> - 6efcc1d
- chore: copyright update
* Fri Jan 26 2024 Ben Grande <[email protected]> - a04960c
- feat: initial split-mail setup
* Sat Jan 20 2024 Ben Grande <[email protected]> - 422b01e
- feat: remove audiovm setting when unnecessary
* Wed Dec 20 2023 Ben Grande <[email protected]> - dbaa386
- chore: inline dev install documentation
* Mon Dec 18 2023 Ben Grande <[email protected]> - 9fc2c03
- doc: top method must not skip dom0
* Mon Nov 20 2023 Ben Grande <[email protected]> - 5e3c790
- fix: mode ansible linter to correct project
* Mon Nov 13 2023 Ben Grande <[email protected]> - 5eebd78
- refactor: initial commit
