all config files should be used from the source, not external locations

[adrelanos]

I noticed the build script downloads a file form https://update.securix.org/install/conf.tar.gz, extracts and installs it.

This is "intransparent". When building from source code, for security reasons, it's better if all files created by securix are managed in the source management system (git) and not downloaded from external resources. (Unless they're a git sub(module|folder|...).) They're maybe already in the git source folder, but why not copy the files from the source folder to the hdd. Why download them from an external resource.

It makes forking and understanding securix much harder. Forking not necessarily in a sense that someone maintains another project as a fork. Just if a builder wants to modify a config file but otherwise leave things as is. The builder would have to create its own conf.tar.gz and make it downloadable rather than just changing the file in git.

So I am very much in favor of not downloading conf.tar.gz from an external location.

[martinholovsky]

I didn't count with git from the beginning, but as it looks I have to.

You're right, all files in conf.tar.gz are visible, just sitting in different folder, so users can review them. https://update.securix.org/config/

For inline patching of files has been planned to use f_updateconfig()

[adrelanos]

Removed the whonix-gentoo-hardened label just now, because when "option to skip installing securix configuration files --configfiles securix|none" (#59) gets implemented, this does not matter anymore for the Whonix Gentoo Hardened port.

Anyhow. Even if it's not required for Whonix Gentoo Hardened port, I strongly suggest to fix this anyhow. Likely other security cautious users prefer the described behavior of this ticket.

[martinholovsky]

Hi,

there are couple of configuration files in https://github.com/martincmelik/securix/tree/master/system-config Why not to pack them into one file and then extract? What is your solution? Please take on mind that securix.org is not external resource, it is trusted resource.

[adrelanos]

Please take on mind that securix.org is not external resource, it is trusted resource.

From perspective of a security conscious user, it's not trusted. They obtain the source code. Be it from github, gitorious or whatever. Then audit the code for non-maliciousness and security bugs. Or rely on others they trust [who might have done /] did that for specific commits / release tags. Then use that source from that project and only trust that source and no external resources (from their point of view) that could change in meanwhile. [... They're probably not doing that will all the stuff that comes from Gentoo, but one security issue at the time. ...]

Why not to pack them into one file and then extract?

(If you think pack and extract is a good method... [for now] [not saying it's not])

You can pack and extract them if you wish. But this should happen during run of the build script. Being done on the builder's local machine. Pack system-config folder during build script, unpack to desired destination afterwards.

What is your solution?

There are many options. Perhaps depending on the stage of project development.

For make install (of config packages) I like the following very much. (Following snippet is untested. Just to get the idea. Taken from generic makefile make-helper.bsh, which is well tested.)

## (DESTDIR is a very common convention for makefiles.)
[ -n "$DESTDIR" ] || DESTDIR='/'
for d in bin boot dev etc home lib opt sbin srv sys usr var; do
   cp -R "$d" "$DESTDIR"

This allows for low maintenance effort and packaging (ebuilds) later, I think.

For Whonix, we're using Generic Packaging (as discussed https://github.com/Whonix/Gentoo-Port/issues/9). Cleanly split Whonix which was once "one big configuration folder" into multiple packages (comparable to ebuilds). Debs (compareable to Gentoo ebuilds) and a local apt repository (compareable to Gentoo overlays) is dynamically created from source by the build script. Got a lot good feedback and made Whonix much simpler to understand. But it took >1 year until it was organized that way and it's non-perfect. [git submodules are not that pretty.] So it might be a question of effort/time/stage of project development which way to go.