similar to: CEBA-2011:0987 CentOS 5 x86_64 cryptsetup-luks Update

CentOS Errata and Bugfix Advisory 2011:0987 Upstream details at : https://rhn.redhat.com/errata/RHBA-2011-0987.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) i386: 46b5fa919e72f7feeb280b43decc335e cryptsetup-luks-1.0.3-8.el5.i386.rpm dfcf63435dbd6cdd8d1779514329cc4b cryptsetup-luks-devel-1.0.3-8.el5.i386.rpm Source:

Since we're no longer only inspecting LUKS devices, use a more generic name. This rewrite also makes the function clearer. --- options/decrypt.c | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/options/decrypt.c b/options/decrypt.c index d868f70..58f8df9 100644 --- a/options/decrypt.c +++ b/options/decrypt.c @@ -28,6 +28,7 @@ #include

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

On Monday, 7 September 2020 11:43:54 CEST Richard W.M. Jones wrote: > This commit deprecates luks-open/luks-open-ro/luks-close for the more > generic sounding names cryptsetup-open/cryptsetup-close, which also > correspond directly to the cryptsetup commands. > > The optional cryptsetup-open readonly flag is used to replace the > functionality of luks-open-ro. > > The

Note that cryptsetup-reencrypt is a separate package on Fedora, but is already part of the appliance on Debian/Ubuntu. --- appliance/packagelist.in | 1 + daemon/luks.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ generator/actions.ml | 18 ++++++++++++++++++ gobject/Makefile.inc | 2 ++ src/MAX_PROC_NR | 2 +- 5 files changed, 68 insertions(+), 1

On 04/03/15 06:33 PM, Robert Nichols wrote: > On 03/04/2015 03:16 PM, Digimer wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> I created a LUKS encrypted partition via a udev-triggered script on >> 6.6 using --key-file /tmp/foo. This worked fine, and I can decrypt the >> LUKS partition via script and manually using

On Tue, Jan 21, 2020 at 03:07:11PM +0100, Jan Synacek wrote: > The following patch attempts to implement sparsification of > LUKS-encrypted partitions. It uses lsblk to pair the underlying LUKS > block device with its mapped name. Also, --allow-discards was added > by default to luks_open(). > > There are several potential issues that I can think of: > > 1) If and entire

Is there an easy way (cli) to enable a luks encrypted partition after reboot (a partition that was not enabled while booting, because not in the crypttab). I can execute the necessary command stack [1] but just wondering if there is an "enterprise/easy" way to do that ... [1] cryptsetup luksOpen $(blkid -t TYPE="crypto_LUKS" -o device) \ luks-$(cryptsetup luksUUID

CentOS Errata and Bugfix Advisory 2017:3330 Upstream details at : https://access.redhat.com/errata/RHBA-2017:3330 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 05b360cd746586e2cb31c3b5aecfccfa6d46e762a63e17d90fe58c0673ef7958 cryptsetup-1.7.4-3.el7_4.1.x86_64.rpm

Hi people, i had created encrypted device with cryptsetup/LUKS which i setup with an ext4 filesystem. This device is an external USB harddisk. When i plugin this device it will be automatically mounted by my gnome3 system (Debian Wheezey/Testing), but this week i got an error. I did ask the ask the LUKS developers what is the problem and they told me that this is an ext4 problem. The error

On 12/12/2017 08:41 AM, Wells, Roger K. wrote: > I have existing systems with un-encrypted disks. > I have tried unsuccessfully to encrypt them using LUKS. > Has anyone out there been able to encrypt an existing system (after the fact, so to speak)? You can do that with cryptsetup-reencrypt, but it needs to be able to make space for the ~2MB LUKS header ahead of the filesystem in the

Hi, Short version: If I had a CPU with the aes-ni [1] feature would luks use it? I know that Upstream Vendors Security Guide [2] says: ...snip The default cipher used for LUKS (refer to cryptsetup --help) is aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector). Note that the installation program, Anaconda, uses by default XTS mode (aes-xts-plain64) snap... I also found a

On 03/04/2015 03:16 PM, Digimer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I created a LUKS encrypted partition via a udev-triggered script on > 6.6 using --key-file /tmp/foo. This worked fine, and I can decrypt the > LUKS partition via script and manually using --key-file with luksOpen. > > The odd problem is that I can't

On Tue, 2017-12-12 at 09:41 -0500, Wells, Roger K. wrote: > I have existing systems with un-encrypted disks. > I have tried unsuccessfully to encrypt them using LUKS. > Has anyone out there been able to encrypt an existing system (after the > fact, so to speak)? Using cryptsetup to create a LUKS encrypted disk will wipe all the data on an existing disk. Mark > > TIA >

Hi all, I have set up an encrypted partition on a usb key and can now successfully mount it using: cryptsetup luksOpen /dev/DEVICENODE cryptousb mount /dev/mapper/cryptousb /mountpoint My aim is now to do this using HAL and GNOME's Luks integration. I am already asked for the pass phrase after plugging in the device, but I seem to be not allowed to mount it. Do I need to add an fstab entry

Leon Fauster wrote: >> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: >> >> Upgraded a RAID. Copied everything from backup. >> >> And then my manager said I had to encrypt the drive. >> >> I've done that, and made the filesystem, but I can't mount it. >> >> CentOS 6. >> I have the entry in /etc/crypttab, and a key in

> Am 20.06.2017 um 17:12 schrieb m.roth at 5-cent.us: > > Leon Fauster wrote: >>> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: >>> >>> Upgraded a RAID. Copied everything from backup. >>> >>> And then my manager said I had to encrypt the drive. >>> >>> I've done that, and made the filesystem, but I can't

I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab. I only found this with grep -i luks /var/log/anaconda/anaconda.*: /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: LUKS.__init__:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I created a LUKS encrypted partition via a udev-triggered script on 6.6 using --key-file /tmp/foo. This worked fine, and I can decrypt the LUKS partition via script and manually using --key-file with luksOpen. The odd problem is that I can't decrypt the partition using the prompt. If I manually create a file with the passphrase in it