Allow users to add free-form text to qubes (for descriptions, notes, comments, remarks, reminders, etc.)

[marmarek]

Reported by Oleg Artemiev grey olli on 12 Sep 2014 08:14 UTC
It could be usefull to have a text description for a VM in its
properties to document changes/difference.
https://groups.google.com/d/topic/qubes-users/uYCcOqIeF5k/discussion

Migrated-From: https://wiki.qubes-os.org/ticket/899

[marmarek]

Modified by marmarek on 12 Sep 2014 08:14 UTC

[marmarek]

Comment by joanna on 12 Sep 2014 09:25 UTC
Would be more logical to do that in R3, as part of our qubes.xml revamping.

[Jeeppler]

I would like to work on this issue (see https://groups.google.com/forum/#!topic/qubes-devel/t32l-0BjlLs).

[marmarek]

@bnvk is working on new Qubes Manager, please coordinate.

[Jeeppler]

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

[marmarek]

On Tue, Jul 26, 2016 at 02:10:35PM -0700, Jeppler wrote:

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

I think this may be simply a VM property, accessible using qvm-prefs.
How to present it in GUI is unrelated to this ticket.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jeeppler]

Perfect. @marmarek are you considering to implement it as qvm-prefs property in Q R4?

[andrewdavidwong]

It's worth thinking about how this is related to #865, i.e., defining and disambigutating these possible properties of VMs:

• Description
• Tag
• Attribute

[Jeeppler]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

It would be nice to have a "last started" property. This would be helpful to see if the machines are used regularly or have been used a long time ago.

[Jeeppler]

What would be the "Attribute" property? It seems a little bit generic.

[andrewdavidwong]

Yes, "last started" would be useful, especially when trying to decide whether a VM needs to be included in a backup. (If the "last started" date is the same or earlier than the "last backup" date, then it probably doesn't need to be backed up again.)

But this is different from a "VM description," so here's a new issue for it: #2230

[marmarek]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

Yes, that's how it is in Qubes 4.0.

What would be the "Attribute" property? It seems a little bit generic.

That's generic name for tag with some value (so, not only "present"/"absent") ;)

[marmarek]

But if we allow non-ASCII characters in description.txt, which also gets imported and rendered in dom0, then we've reintroduced adversary-controlled non-ASCII text rendered in dom0. Is that a problem?

Ah, indeed this may be a problem. I see a few options:

• don't import description.txt as part of the VM importing
• strip it of dangerous characters (which also will include <, & etc, to avoid triggering some HTML or other parsers)

[rootkovska]

1. I like keeping description as a separate file, not to pollute the XML file.

2. I think coming up with a general method to sanitize description would be tricky. We don't know what widget/application will finally want to display it. This is potentially much harder to reasonable sanitation of titlebars.

3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it only for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

4. We should aim at treating any qvm-backup-restore operation as potentially untrusted. The ultimate goal for qvm-backup-restore should be that, even if the backup was made on a compromised Qubes system, than the new system (where we restoring to) should not get compromised -- i.e. neither Dom0, nor the hypervisor, and firmware, etc, should not be affected (this of course assumes the user opting out from restoring the Dom0 home dir, which often can be used with minimal PITA).

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

[marmarek]

On Sat, Apr 01, 2017 at 04:32:15AM -0700, Joanna Rutkowska wrote: 3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it _only_ for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

Yes, we can simply ignore this file during VM import - this will be a separate tool, so it can have separate logic for handling this.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

If qvm-backup-restore is the tool used to import VMs that have been created (and potentially shared) with the qvm-export-vm tool (#1747), then yes. However, #1747 doesn't specify whether it would be qvm-backup-restore or a new tool, e.g., qvm-import-vm.

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

Ok, sounds like it would indeed be a new tool (e.g., qvm-import-vm).

[rootkovska]

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

But the doesn't solve the problem that we still want to have qvm-backup-restore to be resistant to a compromise if the previous system (on which qvm-bakup/qvm-export were run) was compromised.

Perhaps a solution to this would be to add a switch to qvm-backup-restore: e.g. `--distrust-backup", which would imply: 1) don't restore Dom0 homedir, 2) ignore VM description files, 3) perhaps some other things, TBD in another ticket.

And, yes, having a separate qvm-import tool, which always ignores description.txt files.

[marmarek]

See #899 (comment) why it isn't a good idea.

[andrewdavidwong]

(Consolidated several duplicate issues into this one, increased priority, and removed "help wanted." They were last set many years ago, and there seems to be noticeable demand for this feature. This is just to prompt reevaluation, not any kind of authoritative decision. @marmarek, feel free to put them back.)

[HerzogM]

I really hope this will be addressed. I keep finding myself wanting to have a textbox in a qube’s settings to make remarks, comments or a description for that qube. Things I want to remember for that qube, a description for how this qube is intended to be used, warnings, hints etc.
The name field for the qube is not sufficient for this purpose and it would result in too long qube names if I made the name too verbose. So maybe the devs can consider giving the settings a textarea for this purpose?

[DemiMarie]

Assigning to @marmarta because the vast majority of the work here is UX related. The backend part (saving stuff in qubes.xml) is trivial in comparison.