Salt formula - best practices for setting up Veracrypt in a template?

I’m currently working on a salt formula to setup my Qubes install. I’m trying to get Veracrypt installed in a TemplateVM, however Veracrypt is not available in any repos meaning it needs to be downloaded and installed manually.

Question 1:

I am assuming the appropriate way to do this in a salt formula would be:

  • Create the TemplateVM
  • Open a DisposableVM and download the .rpm & verify the hash of the file
  • If the hash matches copy the .rpm from the DisposableVM to the TemplateVM
  • Install the .rpm in the TemplateVM

Do I have that right?

Question 2:

With respect to downloading Veracrypt, would best practices be to download the .rpm from the Github page: Releases · veracrypt/VeraCrypt · GitHub
The download link would be:

Or alternatively from the veracrypt website downloads page: VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
The download link would be:

Which is the better source? Im guessing the launchpad link has more potential to be compromised?


i use the Generic Installers , i extract “veracrypt-1.26.7-setup-gtk3-gui-x64” and store it in my vault, like that, i just have to copy it in the Vm/DispVM when i want to use it. Like that, i just have to do a ./veracrypt-1.26.7-setup-gui-x64 . It take just few seconds to install it and it’s ok for debian or fedora, like that, i don’t have to install it in templates.

1 Like

Provided you trust that you know what the hash should be, and trust the hashing function this seems reasonable.

For verifying a Qubes OS installation file, for example, you’ll be encouraged to verify the authenticity of the reference hash values via a GPG signature, but once that done, the procedure is very much what you describe.

Reference: Verifying signatures | Qubes OS

Suggestion: verify the hashes one more time in the TemplateVM before installing the package.

If you can verify the download via hashes, it doesn’t matter where you downloaded it from, that’s the entire point of the verification. (It’s a notion sometimes called untrusted infrastructure because you don’t need the infrastructure that hosts your packages to be trustworthy in order to ensure the trustworthiness of the packages themselves.)

That being said, verifying downloads only displaces the problem. In order to trust your verification you need to make sure you got the right reference hashes in the first place (i.e. you know what the hashes should be).

One way to get higher assurances of that is to look up several difference sources for the reference hashes (if they’re available!), and/or to look them up over the Tor network (anonymity makes some attacks more expensive and usually doesn’t cost you much).

If I remember correctly, some of that is described in the page linked above, in relation to the Qubes Master Signing Key fingerprint. (If you’ve got a signed set of hashes, you displace the problem one step further: you can get the signed hashes from anywhere but you need to ensure you got the right GPG key.)

1 Like

Thanks for your response, very detailed, exactly what I was looking for.

However, I have one question why would I verify the hash in the DisposableVM and then re-verify the same file in the TemplateVM it has been copied to? All I have done is copied it from the DisposableVM to the TemplateVM - what occur when copying between qubes that would merit the re-verify?

The main reason: copy errors can always happen, and checking a hash takes a few seconds for most packages. (That being said, I’ve never seen qvm-copy fail to copy a file correctly.)

Now, there is another reason, that is arguably bordering the security theather category. (But remember the assumption that checking the hash takes seconds, so it’s very cheap.)

The reason why data shouldn’t be copied from less trusted qubes to more trusted qubes is that a malicious source qube could send whatever it wants to the destination qube. (It would be a very specific form of compromise, but it’s theoretically possible.)

As a side note, that’s the reason why there are few built-in tools to copy to dom0: as the most trusted qube, there should be few times any data is copied into it. (For further theoretical reference, this model of thinking is called the Biba model - Biba Model - Wikipedia)

In the disposable, copy happens after verification, so theoretically, the data that ends up in the template might not (at all, or only) be the package that was verified.

Performing the verification again in the template allows to detect when a very obviously different package was sent by the dispVM, or an error happened during the copy, which is essentially the same.

If that seems to make sense, why do I think it borders security theather? Because in theory, sending a different package is only one way a malicious source qube could behave. It could also send additional data, that we’re not looking for. Or exploit a bug in the checksum programs… in which case it was better not to have run them in the template, etc. :woman_shrugging: In the template, any verification would happen after the copy, and there is no way around that.

Truth is that if you think in terms of Biba model, the moment you copy files from one qube to another, the destination becomes at most as trusted as the source. The moment you decide that you’ll copy the package from the disposable to the template, you’re making the decision to trust the disposable, and to assume that if it was compromised then the verification tools in the template could be as well. What really remains to cover is only the odd copy error which would still be annoying to troubleshoot at installation time and is easy to catch with a checksum.

That’s in theory. In practice, it may be that verifying the checksums in the template most of the time increases the amount of effort needed to compromise it in that way, but honestly we’re splitting hairs at this point and without a concrete risk assessment I don’t think agonizing on this is a useful to way spend much time.

One last thought on trusting the disposable where you downlodaded the package. That’s likeky fine! Unless I’m missing something, it is not that different from what the secure updates mechanism does (it’s not the same, but it’s similar). The main takeaway from the few paragraphs above is how much effort would need to go into a chain of exploits to compromise a template in that way, especially if you’ve only got the time of a download to compromise the disposable qube. Not exposing the template to the internet or to any qube with significant internet exposure goes a long way.

With that in mind, what would I do to take advantage of the disposablility of the dispVM and the tools available in Qubes OS to lower the risk?

  • always use a new disposable
  • download the package over Tor (implies Whonix disposable)
  • not do anything else in that disposable than downloading the file and verifying it (implies the first point, indeed)
  • keep the internet / Tor connection open only for as long as necessary to download the package (the NetVM can be removed in the settings while the qube is running, that’s no problem)

I hope this makes sense :slightly_smiling_face:


Makes perfect sense, thankyou so much!

1 Like