Re: [qubes-devel] separate frequency of read/write operations by mount points?

On Sat, Feb 18, 2017 at 01:07:02PM -0700, Trammell Hudson wrote: > On Sat, Feb 18, 2017 at 10:45:31PM +0300, Oleg Artemiev wrote: > > [...] > > AFAIR, when App VM is started some image files are made. Are these > > files are made in /var/lib/qubes/appvms or also in > > /var/lib/qubes/vm-templates

Re: [qubes-devel] Deniable encryption to combat forced key disclosure

On Thu, Oct 27, 2016 at 04:34:10PM +, entr0py wrote: > Andrew David Wong: > > On 2016-10-26 16:19, tonyinfin...@tutanota.com wrote: > >> I've tried to search this topic but not come to any clear answers. > > > >> Are there any plans to implement this for Qubes? > > > >> Usecase: If you are

Re: [qubes-devel] Re: GitLab

On Sun, May 14, 2017 at 02:11:30PM -0500, Andrew David Wong wrote: > > Unfortunately the tools to actually find these paths all kinda suck, but > > they > > do at least the paths exist. The one I used to find the above is > > https://pgp.cs.uu.nl/, however it has the significant limitation that

Re: [qubes-devel] Re: GitLab

On Sun, May 14, 2017 at 09:45:13PM -0500, Andrew David Wong wrote: > >> (2), meanwhile, requires transferring the key to the QMSK's environment > >> via: > > > > > > > > We're in agreement that's a less-than-wise idea. :) > > > > Great points. Thanks! I think your setup would have been

Re: [qubes-devel] Re: GitLab

On Sun, May 14, 2017 at 09:57:45PM -0400, Jean-Philippe Ouellet wrote: > > Let's assume that (5) would be too cumbersome and error-prone to qualify > > as "practical." (3) would, again, entail that the machine is no > > longer airgapped. (4) is inherently risky. The riskiest storage media > > are,

Re: [qubes-devel] Re: GitLab

On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote: > There are many other methods you could use to attempt to verify the > master key fingerprint aside from relying on the Qubes website. Here's > a brief, non-exhaustive list: > > * Use different search engines to search for the

Re: [qubes-devel] ipv6 for internal network in 4.x?

On Fri, May 26, 2017 at 09:07:43PM -0700, pixel fairy wrote: > since qubes needs to adopt ipv6 eventually anyway, can we make the internal > network v6? > > v6 nat is the same as v4, but you would have to alert qubes when there is > no external v6 route. this will also be true when there is no

Re: [qubes-devel] ipv6 for internal network in 4.x?

On Sun, May 28, 2017 at 05:46:22AM -0700, pixel fairy wrote: > > > > > > Are you suggesting that VM's no longer have internal ipv4 addresses? You > > mean > > via the ipv4-in-ipv6 address range or something else? > > > > i was thinking dual stack and nat for both 4 and 6. my first thought

Re: [qubes-devel] Future-proofing qubes-secpack

On Sun, Jun 04, 2017 at 04:45:32PM -0500, Andrew David Wong wrote: > My next question was going to be whether you're aware of Peter Todd's > OpenTimestamps project, which Jean-Philippe mentioned. Also see: > > https://petertodd.org/2016/opentimestamps-announcement >

Re: [qubes-devel] Future-proofing qubes-secpack

On Sun, Jun 04, 2017 at 05:29:46AM -0700, Axel wrote: > I did not see that pull request. Note however that the pull request makes > qubes-secpack depend on the blockchain in order to prove information > creation *after* a certain point in time, while my suggestion was the > opposite: make the

Re: [qubes-devel] Future-proofing qubes-secpack

On Mon, Jun 05, 2017 at 03:17:46PM -0700, Axel wrote: > > I think that indirection just confuses the issue, so better to put the > > proof-of-freshness in the signature itself. Fortunately the OpenPGP > > standard > > has something called "signature notation data" that allows you to add > >

Re: [qubes-devel] How secure is Qubes dom0 backup tool encryption?

On Sun, May 07, 2017 at 12:49:06PM -0500, Andrew David Wong wrote: > They're not mutually exclusive. You can do both. > > I'm the one who reported the key derivation issue [1], but even I > think qvm-backup is plenty safe as long as you use a high-entropy > passphrase. (This will no longer be an

Re: [qubes-devel] Future-proofing qubes-secpack

On Mon, Jun 05, 2017 at 11:15:33AM -0700, Axel wrote: > > Bitcoin block hashes are a chain, so it doesn't make any sense to include > > more > > than one, unless you're worried about reorgs. > > > > Agree. reorgs are the only reason to include more than one, but 10 seems > like overkill.

Re: [qubes-devel] Remove SWAP file on SSD systems / provide option in installer

On Tue, Sep 26, 2017 at 03:43:27AM -0400, taii...@gmx.com wrote: > It increases SSD wear and decreases privacy by writing temporary data to > disk (no bueno!), I believe an option should be provided in the installer > for this. Re: privacy, you can setup swap files to use encrypted storage with

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 10:28:15AM -0500, Konstantin Ryabitsev wrote: > On 08/11/17 10:51 PM, Jean-Philippe Ouellet wrote: > >I could of course verify the signature of the auto-generated > >sha256sums.asc file which covers all the files (including compressed > >ones), but that means trusting

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 01:29:15PM -0500, Konstantin Ryabitsev wrote: > >The thing is developer workstations are *already* trusted, because if those > >workstations are compromised they can compromise the code itself, which in > >practice is quite difficult to effectively audit. So why add an

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 02:01:24PM -0500, Konstantin Ryabitsev wrote: > >I do agree that theres more potential for a change in git to be noticed, but > >I > >have to wonder how much that's actually true in practice? A backdoor can > >easily > >be a one character code change, and that's rather

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 01:59:41PM -0500, Jean-Philippe Ouellet wrote: > I might be misunderstanding how all this works, but maybe what we actually > need > > here is a new type of tarball signature verifier, that takes the GPG > > signature > > from the signed git commit, and verifies that

Re: [qubes-devel] A first stab at an open source GUI for Qubes

On Wed, Dec 20, 2017 at 11:32:44PM +0100, Marek Marczykowski-Górecki wrote: > Thanks for the heads-up! Library for native extensions definitely would be > useful. Generally we try to use python wherever possible, mostly because > of its memory-safety (debugging memory corruption bugs can be a >

Re: [qubes-devel] Announcement: Fedora 26 TemplateVM Upgrade

On Sat, Jan 06, 2018 at 06:15:21PM -0600, Andrew David Wong wrote: > Dear Qubes Community, > > Fedora 25 reached EOL ([end-of-life]) on 2017-12-12. We sincerely > apologize for our failure to provide timely notice of this event. It > is strongly recommend that all Qubes users upgrade their Fedora

Re: [qubes-devel] Announcement: Fedora 26 TemplateVM Upgrade

On Sun, Jan 07, 2018 at 02:48:29PM -0600, Andrew David Wong wrote: > This is a known issue: > > https://github.com/QubesOS/qubes-issues/issues/3442 > > You can simply use `--best --allow-erasing`. Thanks! That worked. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this

Re: [qubes-devel] A first stab at an open source GUI for Qubes

On Thu, Dec 21, 2017 at 12:38:00PM +0100, Marek Marczykowski-Górecki wrote: > On Wed, Dec 20, 2017 at 11:56:24PM -0500, Peter Todd wrote: > > On Wed, Dec 20, 2017 at 11:32:44PM +0100, Marek Marczykowski-Górecki wrote: > > > Thanks for the heads-up! Library for native extension

Re: [qubes-devel] R4.0-rc4 installation image considerations

On Sat, Jan 20, 2018 at 11:54:11AM +, Andrew Clausen wrote: > Hi all, > > On 20 January 2018 at 09:28, Ivan Mitev wrote: > > > +1 > > > > Other people in the thread disagree and still use regular DVDs - which as > > a readonly media is great for security - but how may people

Re: [qubes-devel] Timestamp canaries

On Fri, Mar 09, 2018 at 12:19:47PM -0800, theinnovativeinven...@gmail.com wrote: > I was looking at the canaries, and I liked the idea of a proof of freshness > with the latest news headlines. While people can't create canaries ahead of > time, it is possible to conspire to modify or backdate

Re: [qubes-devel] Timestamp canaries

On Sat, Mar 10, 2018 at 07:19:11PM +0100, Marek Marczykowski-Górecki wrote: > Is there any sensible way of installing OTS client securely? There is a > chain of dependencies which are not packaged for neither Debian or > Fedora (python-opentimestamps, bitcoinlib, pysha3, ...). And since pip > rely

Re: [qubes-devel] Re: Timestamp canaries

On Mon, Mar 19, 2018 at 12:12:13AM +0100, Marek Marczykowski-Górecki wrote: > > > I wasn't aware of the NIST Randomness Beacon. Very interesting. Thanks > > > for bringing it to my attention. As far as I can tell, this looks like a > > > very good source for the Proof of Freshness. Would you like

Re: [qubes-devel] Addressing the long shutdown time with LVM thin volumes

On Fri, Feb 05, 2021 at 06:59:05PM +0100, donoban wrote: > On 2/5/21 5:24 PM, Jinoh Kang wrote: > > Possible solutions would be: > > > > - Patch dm-thin. Now to implement this properly, dm-thin must first > > slice the range, have it ref'd somewhere and then issue discards (so > > that it

Re: [qubes-devel] Addressing the long shutdown time with LVM thin volumes

On Thu, Feb 11, 2021 at 11:02:51AM +, Rusty Bird wrote: > Peter Todd: > > On Fri, Feb 05, 2021 at 06:59:05PM +0100, donoban wrote: > > > On 2/5/21 5:24 PM, Jinoh Kang wrote: > > > > - Switch to reflinks. BTRFS has been around 10+ years, so I assum