Gtk::Menu_Helpers::Element class and subclasses help in Gtk::MenuItem
widgets and also automate tasks like registering keyboard accelerators
when parented to a top-level window [1][2].
Gtk::Menu_Helpers::Element class and subclasses were removed in Gtkmm3
[3]. Provide compatible implementations under the namespace
GParted::Menu_Helpers.
References:
[1] gtkmm: Gtk::Menu_Helpers Namespace Reference
https://developer.gnome.org/gtkmm/2.24/namespaceGtk_1_1Menu__Helpers.html
[2] gtkmm: Gtk::Menu_Helpers::Element Class Reference
https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Menu__Helpers_1_1Element.html
[3] Gtkmm 3 commit "MenuShell: Remove items()." removed the code
c8e47b0db5Closes#7 - Port to Gtk3
There is no prospect of there being ufs-tools on Linux. The was a
project which did release ufs-tools version 0.1 in 2004, but has been
inactive since then.
http://ufs-linux.sourceforge.net/
Copying and moving is now implemented for file systems in the basic
supported category. Also mounting and unmounting of unsupported file
system and reporting their usage while mounted has been added. This is
all the support that GParted has ever implemented for UFS. Therefore
re-assign UFS as a basic supported file system as it looses no
functionality.
Closes!13 - Support copying and moving of unsupported partition content
Util-linux package, at least as far back as version 2.23.2 as found on
CentOS 7, provides the mkfs.minix and fsck.minix commands. Also blkid
from the same package, recognises minix file systems.
Create version 3 file systems because MINIX 3 [1] is the only supported
version and that reportedly uses version 3 of the file system [2].
[1] MINIX 3 / History
https://en.wikipedia.org/wiki/MINIX_3#History
[2] Regarding MINIX 3 file system
https://groups.google.com/forum/#!topic/minix3/3-TeHR_23X8
"MINIX 3 uses Minix File System (MFS). More precisely MFS V3."
Closes!12 - Add minix file system support
The translations which have been updated for the 0.32.0 release, and
since the migration to GitLab hosting, have been updated with the new
GitLab issue bug reporting URL. Update all the remaining translation
files to match.
Closes!11 - Update bugzilla references
Initial addition of a password entry dialog. Looks like:
+------------------------------------------------+
| LUKS Passphrase /dev/sdb1 |
+------------------------------------------------+
| Enter LUKS passphrase to open /dev/sdb1 |
| Passphrase: [ ] |
| |
| [ Cancel ] [ Unlock ] |
+------------------------------------------------+
A standard Gtk Dialog is used to accept the password once, with any
errors displayed in a separate error dialog afterwards. This is poor UI
design. A password dialog should remain open for all authentication
attempts and only close when successful or the dialog is cancelled or
closed. This UI design issue will be improved in following commits.
Bug 795617 - Implement opening and closing of LUKS mappings
Application level requirements for secure password management were set
out in "LUKS password handling, threats and preventative measures" [1].
The requirements are:
1) Passwords are stored in RAM and are not allowed to be paged to swap.
(However hibernating with GParted still running will write all of RAM
to swap).
2) Passwords are wiped from RAM when no longer needed. When each
password is no longer needed and when GParted closes.
3) Passwords are referenced by unique key. Recommend using LUKS UUIDs
as the unique key.
(Each LUKS password should only ever need to be entered once for each
execution of GParted. Therefore the passwords can't be stored in any
of the existing data structures such as Partitions or LUKS_Info cache
because all of these are cleared and reloaded on each device
refresh).
There seems to be two possible implementation methods: use an existing
library to provide secure memory handling, or write our own.
Libgcrypt [2] and libsodium [3] cryptographic libraries both provide
secure memory handling. (Secure memory is quite simple really, some
virtual memory locked into RAM which is zeroed when no longer needed).
Linking to an encryption library just to provide secure memory seems
like using a sledge hammer to crack a nut. Also because of requirement
(3) above a module is needed to "own" the pointers to the passwords in
the secure memory. Managing the secure memory ourselves is probably no
more code that that needed to interface to libgcrypt. Therefore handle
the secure memory ourselves.
So far the module is only compiled. It is not used anywhere in GParted.
[1] LUKS password handling, threats and preventative measures
https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56
[2] libgcrypt general purpose cryptographic library, as used in GNU
Privacy Guard
https://gnupg.org/related_software/libgcrypt/
[3] libsodium crypto library
https://download.libsodium.org/doc/
Bug 795617 - Implement opening and closing of LUKS mappings
Jordi Mas