Bug#995986: simple-cdd: Firmware not being included in installer image
I can confirm that this issue still seems to affect simple-cdd 0.6.9 on bookworm as of mid-May 2023 (including debian-cd version 3.2.1). I too have tried 'export FORCE_FIRMWARE=1' together with 'export NONFREE_COMPONENTS="non-free non-free-firmware"', 'mirror_components="main non-free non-free-firmware"' and various combinations thereof within my profile.default, all without success. It would be great to see a working example of how to get firmware packages managed by simple-cdd. Thanks.
Bug#1019550: cryptmount: [INTL:de] updated German po file translation
Thanks, Helge - that's very helpful. I'll roll this into the next release of cryptmount. Your changes should also be visible in the (new) GitHub repository at https://github.com/rwpenney/cryptmount/commit/e631e0d98238618c455f409292618f624ab80c3a
Bug#978114: cryptmount: [INTL:de] updated German po file translation
Danke, Helge. I'll include your updated translations in the next (bugfix) release of cryptmount. Kind regards, RW Penney
Bug#888444: cryptmount: Got errno=95 when run as not-root
I think I've found the origin of the problem, and this is related to a change made within libcryptsetup during January 2017, in the function device_internal_prepare(). This now checks that both getuid() and geteuid() return zero before attempting to configure a loopback device. Other areas of libcryptsetup will check getuid() and geteuid() after an operation fails in order to provide a warning message about lack of root privileges. I'm not convinced that checking getuid() is necessary, if geteuid() already returns zero. I have a provisional fix for cryptmount, which I intend to roll into the forthcoming release 5.3.
Bug#888444: cryptmount: Got errno=95 when run as not-root
Hello Andrey, Thanks for finding this issue with cryptmount, and for your helpful stack traces and configuration information. I am still investigating this issue, and have created a new test specifically for LUKS partitions within ordinary files to help narrow-down the source of the problem. Could you confirm that in your case, the LUKS container is in an ordinary file on a local filesystem (e.g. there are no NFS/SSHFS/NTFS filesystems involved)? I've confirmed that cryptmount does handle these files as intended on debian-jessie, debian-stretch, ubuntu-artful, but there do seem to be issues with debian-buster and fedora-27. All functionality relating to handling LUKS containers within ordinary block devices (e.g. hard-disk partitions), or filesystems in ordinary files managed by other cryptmount keymanagers (e.g. "builtin", "libgcrypt") seems to be working as it should. I hope to be able to provide a fix soon. RW Penney
Bug#823076: cryptmount: Fix LSB init output
Hello Guillem, Thanks for your suggested improvement to the cryptmount init.d script, and for your helpful patch. I have just released version 5.2.1 of cryptmount, which incorporates your improvements. I hope this will soon be available as a Debian package. Kind regards, RW Penney
Bug#779851: cryptmount: Me neither, but different failure mode
Thanks for reporting this bug. I think I have diagnosed the problem - this is probably due to a change in behaviour of /sbin/fsck, where it now relies on the PATH environmental variable to find /sbin/fsck.ext3 etc. instead of just searching /sbin and a few other standard places. That is a significant difference from the version of fsck in Jessie. I'm currently working on a fix for this, which will probably form part of (upstream) release cryptmount-5.2. As a work-around, you could temporarily disable fsck by using "flags=nofsck" in /etc/cryptmount/cmtab.
Bug#798358: cryptmount: fails to install: cryptmount.postinst: deb-systemd-helper: not found
cryptmount-5.1-3 is available now at http://www.rwpenney.org.uk/software/index.html#cryptmount . I am hoping my sponsor will be able to upload it into Sid soon.
Bug#798358: cryptmount: fails to install: cryptmount.postinst: deb-systemd-helper: not found
Hello Andreas, Thanks for reporting this bug. I have already been working on a cleaner version of the postinst script making better use dh-systemd, which should fix other piuparts problems relating to unwanted files left after uninstallation. I hope to have a 5.1-3 available very soon. Thanks, RW Penney
Bug#795440: cryptmount-setup fails and can't recover when user mistypes initial passphrase
David, Thanks for finding this issue with the cryptmount-setup script. I'm currently looking into a fix that will form part of the next upstream release of cryptmount. In case you haven't already found a work-around, the cryptmount man-page describes (in the example usage section) a recipe that roughly matches the steps in the setup script. If you follow that man-page entry from the line cryptmount --generate-key 32 opaque (changing opaque to the name of your encrypted filesystem), that should allow the setup process to complete. Cheers, RW Penney
Bug#795322: cryptmount: FTBFS: assumes automake-1.14
For info, attached is a patch (relative to cryptmount-5.1-1)
which I believe fixes the automake issue, as well as the outstanding
lintian warnings.
diff --git a/debian/changelog b/debian/changelog
index 86f7fa1..eba7e8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+cryptmount (5.1-2) unstable; urgency=medium
+
+ * Patched installation path for cryptmount.service to be beneath /lib/systemd
+
+ * Improved postinst/postrm support for systemd
+
+ * Removed duplicated example configuration file
+
+ * Rebuilt debian/rules script to use debhelper v7 and dh_autoreconf
+
+ -- RW Penney rwpen...@users.sourceforge.net Sun, 26 Jul 2015 12:00:00 +
+
cryptmount (5.1-1) unstable; urgency=low
* Updated to version 5.1 of upstream package
diff --git a/debian/control b/debian/control
index 10ec589..50e11b6 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: extra
Maintainer: RW Penney rwpen...@users.sourceforge.net
Homepage: http://cryptmount.sourceforge.net
Build-Depends: debhelper (= 9.0.0), dpkg-dev (=1.16.1),
-automake, autotools-dev,
+automake, dh-autoreconf,
libcryptsetup-dev (= 1.6), libdevmapper-dev,
libgcrypt20-dev (= 1.5), pkg-config
Standards-Version: 3.9.6
diff --git a/debian/cryptmount.lintian-overrides b/debian/cryptmount.lintian-overrides
new file mode 100644
index 000..698a82d
--- /dev/null
+++ b/debian/cryptmount.lintian-overrides
@@ -0,0 +1,4 @@
+# lintian-override for cryptmount
+
+# cryptmount needs to have setuid privileges to be usable by ordinary users:
+cryptmount: setuid-binary usr/bin/cryptmount 4755 root/root
diff --git a/debian/dirs b/debian/dirs
index e453b9c..fa9d077 100644
--- a/debian/dirs
+++ b/debian/dirs
@@ -1,7 +1,6 @@
etc/cryptmount
-etc/init.d
etc/modules-load.d
-usr/lib/systemd/system
+lib/systemd/system
usr/share/doc/cryptmount/examples
usr/share/man
usr/share/lintian/overrides
diff --git a/debian/lintian-override b/debian/lintian-override
deleted file mode 100644
index 698a82d..000
--- a/debian/lintian-override
+++ /dev/null
@@ -1,4 +0,0 @@
-# lintian-override for cryptmount
-
-# cryptmount needs to have setuid privileges to be usable by ordinary users:
-cryptmount: setuid-binary usr/bin/cryptmount 4755 root/root
diff --git a/debian/patches/autotools-fixes.patch b/debian/patches/autotools-fixes.patch
new file mode 100644
index 000..90e16e2
--- /dev/null
+++ b/debian/patches/autotools-fixes.patch
@@ -0,0 +1,38 @@
+--- a/Makefile.am
b/Makefile.am
+@@ -5,7 +5,6 @@
+ -DCM_SYSRUN_DIR=\$(CM_SYSRUN_DIR)\ \
+ -DCM_MODULE_DIR=\$(pkglibdir)\
+
+-ACLOCAL_AMFLAGS = #-I m4
+ bin_PROGRAMS=cryptmount
+ cryptmount_SOURCES=cryptmount.c cryptmount.h \
+ armour.c armour.h \
+@@ -30,7 +29,7 @@
+ EXTRA_DIST = config.rpath mkinstalldirs cmtab.example \
+ README.OpenSSL RELNOTES ToDo cryptmount.spec \
+ debian/changelog debian/compat debian/control debian/copyright \
+- debian/dirs debian/docs debian/rules debian/lintian-override \
++ debian/dirs debian/docs debian/rules debian/cryptmount.lintian-overrides \
+ debian/postinst debian/postrm debian/watch debian/source/format \
+ debian/upstream/signing-key.asc
+
+--- a/Makefile.in
b/Makefile.in
+@@ -358,7 +358,6 @@
+ -DCM_SYSRUN_DIR=\$(CM_SYSRUN_DIR)\ \
+ -DCM_MODULE_DIR=\$(pkglibdir)\
+
+-ACLOCAL_AMFLAGS = #-I m4
+ cryptmount_SOURCES = cryptmount.c cryptmount.h \
+ armour.c armour.h \
+ armour-builtin.c armour-gcry.c armour-luks.c \
+@@ -376,7 +375,7 @@
+ EXTRA_DIST = config.rpath mkinstalldirs cmtab.example \
+ README.OpenSSL RELNOTES ToDo cryptmount.spec \
+ debian/changelog debian/compat debian/control debian/copyright \
+- debian/dirs debian/docs debian/rules debian/lintian-override \
++ debian/dirs debian/docs debian/rules debian/cryptmount.lintian-overrides \
+ debian/postinst debian/postrm debian/watch debian/source/format \
+ debian/upstream/signing-key.asc
+
diff --git a/debian/patches/series b/debian/patches/series
index 57f58cd..5aca477 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,4 @@
+systemd-paths.patch
install-example-cmtab.patch
init.d-script.patch
+autotools-fixes.patch
diff --git a/debian/patches/systemd-paths.patch b/debian/patches/systemd-paths.patch
new file mode 100644
index 000..28d0c4c
--- /dev/null
+++ b/debian/patches/systemd-paths.patch
@@ -0,0 +1,17 @@
+--- a/sysinit/Makefile.am
b/sysinit/Makefile.am
+@@ -26,11 +26,11 @@
+
+ install-inits: cryptmount.service initscript
+ if USE_SYSTEMD
+- test -d ${DESTDIR}/usr/lib/systemd/system || mkdir -p ${DESTDIR}/usr/lib/systemd/system
++ test -d ${DESTDIR}/lib/systemd/system || mkdir -p ${DESTDIR}/lib/systemd/system
+ test -d ${DESTDIR}/etc/modules-load.d || mkdir -p ${DESTDIR}/etc/modules-load.d
+ endif # USE_SYSTEMD
+- if test -d ${DESTDIR}/usr/lib/systemd/system ; then \
+- ${INSTALL_PROGRAM_ENV} ${INSTALL_DATA} cryptmount.service ${DESTDIR}/usr/lib/systemd/system; \
++ if
Bug#795322: cryptmount: FTBFS: assumes automake-1.14
Thanks for your bug-report. I have already been working on fix for this issue, and have cryptmount-5.1-2 awaiting upload with the support of my sponsor. For the time being, these packages are available at http://www.rwpenney.org.uk/software The new build-system uses debhelper v7 and dh-autoreconf, so should be a more robust solution in the long term. RW Penney
Bug#779851: cryptmount: Cannot mount as non-root user
Hello Gilles, Thanks for your bug report about cryptmount, and the helpful reference to bug #759263. I've just re-run the cryptmount test-suite on my Jessie test system, and all the tests seem to pass. I suspect this means that the problem you're having is not related to bug #759263, which was caught by the test-suite. From your description, I'm guessing that your encrypted filesystem may live on a network share (mounted under /home/gilles/mnt ?). This isn't a use-case that I've tried, especially with LUKS encrypted filesystems, and I'm not sure whether it's an intended use-case for libcryptsetup. If you are indeed using a network share, it might be worth trying the same setup steps, but with the encrypted container somewhere on your local disk. If the network share is the source of problems, then you might like to try a different keymanager within cryptmount. Perhaps you can let me know the result of those experiments? Thanks, RW Penney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759263: cryptmount: Failed to initialize device for LUKS keyfile
This bug seems to be related to apparent incompatibilities between the
latest libcryptsetup and libgcrypt11. Preliminary experiments with
libgcrypt20 indicate that the problems with non-privileged access to
LUKS partitions can be fixed simply by compiling with libgcrypt20-dev
in place of libgcrypt11-dev.
The attached patch describes these changes. After a bit more testing,
I hope to have an updated (minor) release available soon.
RW Penney
diff --git a/debian/control b/debian/control
index 245d9d6..de31c79 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,12 @@ Priority: extra
Maintainer: RW Penney rwpen...@users.sourceforge.net
Homepage: http://cryptmount.sourceforge.net
Build-Depends: debhelper (= 9.0.0), dpkg-dev (=1.16.1), autotools-dev,
-libcryptsetup-dev (= 1.4), libdevmapper-dev,
-libgcrypt11-dev (= 1.1), pkg-config, uuid-dev
+libcryptsetup-dev (= 1.6), libdevmapper-dev,
+libgcrypt20-dev (= 1.1), pkg-config
Standards-Version: 3.9.5
Package: cryptmount
-Architecture: any
+Architecture: linux-any
Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: udev
Suggests: openssl, dmsetup
Bug#759263: cryptmount: Failed to initialize device for LUKS keyfile
Hello Dave, Thanks for your helpful bug report. It would appear that this issue is related to changes in libcryptsetup between versions 1.6.4 and 1.6.6 (which has just entered debian-testing). The issue you've identified may be related to changes in libcryptsetup connected with allowing non-privileged users to access certain LUKS functions provided that they have read access to the given device. I'll need to do some investigation to see whether this is something that is triggered by cryptmount misusing the cryptsetup API, or whether there is some form of workaround. Kind regards, RW Penney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738736: cryptmount: Placeholder @ETCDIR@ appears in /usr/sbin/cryptmount-setup
Hello Steve,
Thanks for identifying this issue with @ETCDIR@,
and for filing a bug-report.
I've attached a patch which should sort out the issue.
I hope to have an updated release of cryptmount available soon.
Kind regards,
RW Penney
diff --git a/sysinit/Makefile.am b/sysinit/Makefile.am
index 8e1e044..f42ede6 100644
--- a/sysinit/Makefile.am
+++ b/sysinit/Makefile.am
@@ -5,7 +5,7 @@ EXTRA_DIST = cryptmount.service.in modules-load.conf \
setupscript.sh.in initscript.in
scripttransform='s,@EXENAME@,$(bindir)/cryptmount$(EXEEXT),g; \
- s,@CM_SYSCONF_DIR@,$(CM_SYSCONF_DIR),g; \
+ s,@SYSCONF_DIR@,$(CM_SYSCONF_DIR),g; \
s,@PKG_NAME@,$(PACKAGE_NAME),g; \
s,@PKG_VERSION@,$(VERSION),g; \
s,@LCL_DIR@,$(localedir),g'
diff --git a/sysinit/initscript.in b/sysinit/initscript.in
index 98df30f..409407e 100644
--- a/sysinit/initscript.in
+++ b/sysinit/initscript.in
@@ -77,7 +77,7 @@ dofilesys() {
doALL() {
if test -n ${CM_BOOTDV} -o -n ${CM_BOOTSW} \
-o -n ${CM_BOOTFS} -o -n ${CM_EARLYDV}; then
-echo Using /etc/default/cryptmount is DEPRECATED - please use 'bootaction={mount|swap|prepare}' flags within /etc/cryptmount/cmtab
+echo Using /etc/default/cryptmount is DEPRECATED - please use 'bootaction={mount|swap|prepare}' flags within @SYSCONF_DIR@/cmtab
fi
case $1 in
diff --git a/sysinit/setupscript.sh.in b/sysinit/setupscript.sh.in
index 308586a..511adf8 100755
--- a/sysinit/setupscript.sh.in
+++ b/sysinit/setupscript.sh.in
@@ -8,7 +8,7 @@
# for further information.
CM_BINEXE=@EXENAME@
-CM_CFGDIR=@ETCDIR@
+CM_CFGDIR=@SYSCONF_DIR@
# prepare gettext internationalization:
Bug#672678: cryptmount: diff for NMU version 4.3-1.1
Hi Don, Thanks for your efforts in patching this bug in cryptmount. As maintainer, I'm sorry that I wasn't able to get a full version of the package uploaded to the Debian servers as promptly as I would have liked. Hopefully version 4.3.1-1 will be available in sid within the next day or so, with thanks to my Debian sponsor, Laszlo Boszormenyi. Even if your patch wasn't used directly, I really appreciate your taking the time to resolve this release-critical bug. Kind regards, Richard. +-- on Thu, May 24, 2012 at 10:53:25AM -0700, Don Armstrong wrote: ---+ tags 672678 + pending thanks Dear maintainer, I've prepared an NMU for cryptmount (versioned as 4.3-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Don Armstrong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672678: cryptmount: unmet dependency on libdevmapper
Hello Teodor,
Thanks for finding this issue with the cryptmount build-system.
I believe the problem is easily fixed by removing the explicit
dependency on 'libdevmapper' within the debian/control file.
I've attached a patch which seems to sort out the problem on
my debian-sid system, and doesn't seem to have any side effects under
lenny or squeeze.
I hope to have cryptmount-4.3.1 available soon which will incorporate
this fix.
Kind regards,
RW Penney
diff --git a/Makefile.am b/Makefile.am
index 8241c21..2cf9b49 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -116,7 +116,6 @@ clean-local:
-rm -f ${CM_MODULES}
-rm -f ${man_MANS} initscript initscript-early setupscript testing/mudslinger-*-*.log
-rm -f splint.log
- ${MAKE} -C luks clean
dist-hook:
mkdir ${distdir}/testing/keys; cp -p ${srcdir}/testing/keys/[0-9]* ${distdir}/testing/keys/
diff --git a/Makefile.in b/Makefile.in
index 4799d95..c9c303f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -906,7 +906,6 @@ clean-local:
-rm -f ${CM_MODULES}
-rm -f ${man_MANS} initscript initscript-early setupscript testing/mudslinger-*-*.log
-rm -f splint.log
- ${MAKE} -C luks clean
dist-hook:
mkdir ${distdir}/testing/keys; cp -p ${srcdir}/testing/keys/[0-9]* ${distdir}/testing/keys/
diff --git a/debian/control b/debian/control
index e5ec6af..883ce28 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.9.3
Package: cryptmount
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libdevmapper
+Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: udev
Suggests: openssl, dmsetup
Description: Management of encrypted file systems
Bug#656346: Bug fixed
severity 656346 fixed thanks It would appear that the symptoms may have been caused by attempting to execute 'cryptmount --prepare' on a device that already had a mounted filesystem. This condition is apparently trapped by the device-mapper library. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656346: cryptmount --prepare fails
Hello, Thanks for your bug report. I think you'll need to provide some basic information about how you're using cryptmount before I can make any attempt to resolve this bug report. I have frequently tested 'cryptmount --prepare' on a wide range of linux distros, including a broad cross-section of debian systems. Indeed, I have run a pretty extensive testing suite on a debian-6.0.3 system with exactly the same versions of libc6, libgcrypt11, libuuid1 that you cite in your bug report. Those tests have not shown any sign of the problem you mention, nor any sign that cryptmount is generally unusable. Obviously, if you are running into problems with cryptmount, I am keen to understand whether there are bugs that need fixing. However, without more details of how to reproduce the symptoms you are seeing, I cannot make any progress. If you need evidence of the tests that are regularly preformed on cryptmount, you may like to refer to the 'mudslinger' testing program within the cryptmount source distribution. If you can suggest an additional test that should be included in there, that would be especially helpful. Kind regards, RW Penney +-- on Wed, Jan 18, 2012 at 11:55:27AM -0500, gds...@tx.rr.com wrote: ---+ Subject: cryptmount --prepare fails Package: cryptmount Version: 4.1-2 Justification: renders package unusable Severity: grave Tags: l10n *** Please type your report below this line *** Here are the error messages from syslog: Jan 16 20:33:04 far-star kernel: [ 690.357274] device-mapper: table: 254:0: crypt: Error allocating crypto tfm Jan 16 20:33:04 far-star kernel: [ 690.357284] device-mapper: ioctl: error adding target to table And here are the relevant messages from strace: munmap(0xb78b1000, 4096)= 0 ioctl(3, DM_VERSION, 0x9a6d5c0) = 0 ioctl(3, DM_DEV_CREATE, 0x9a6d5c0) = 0 ioctl(3, DM_TABLE_LOAD, 0x9a6d5c0) = -1 EINVAL (Invalid argument) open(/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/en_US/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such file or directory) write(2, device-mapper: reload ioctl fail..., 52device-mapper: reload ioctl failed: Invalid argument) = 52 write(2, \n, 1 ) In a normal workstation/GUI US English installation libc.mo is not in the /usr/share/locale/en/LC_MESSAGES or /usr/share/locale/en_US/LC_MESSAGES directories in Squeeze or Lenny. It is in all (?) the other non-english directories. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cryptmount depends on: ii libc62.11.2-10 Embedded GNU C Library: Shared lib ii libdevmapper1.02.1 [libdevma 2:1.02.48-5 The Linux Kernel Device Mapper use ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libuuid1 2.17.2-9Universally Unique ID library cryptmount recommends no packages. Versions of packages cryptmount suggests: ii dmsetup 2:1.02.48-5 The Linux Kernel Device Mapper use ii openssl 0.9.8o-4squeeze5 Secure Socket Layer (SSL) binary a -- Configuration Files: /etc/cryptmount/cmtab changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641476: cryptmount: permission denied when writing to vfat partition
Hi George, You may like to know that cryptmount-4.3 will now have support for simple environmental variables within /etc/cryptmount/cmtab so that you can use something like 'mountoptions=uid=$(USERNAME)' to give you slightly more flexibility when mounting VFAT partitions. This feature is still in its testing phase, but if you'd like to try it out then there's an alpha release of cryptmount-4.3 available via http://www.sourceforge.net/projects/cryptmount/files/unstable. Kind regards, RWP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641476: cryptmount: permission denied when writing to vfat partition
Hi George, Thanks for your feedback on cryptmount. Have you tried using the 'mountoption' parameter in your /etc/cryptmount/cmtab? One of the options for mounting fat/vfat filesystems is uid=???, which looks like it might be suitable for setting the ownership of the mounted filesystem. If this works, I hope it will be sufficient as a fix for your bug report. I realise that setting 'mountoptions=uid=george' would not work well for other users of your system with whom you might want to share your encrypted filesystem. Perhaps that is a feature I'll look into adding to cryptmount at some stage. Perhaps you can try out the 'mountoptions' idea, and let me know whether it helps? Kind regards, RWP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615865: cryptmount gets device size wrong with optical media
Hello Paul,
Thanks for spotting this issue, and for your patch.
As this may affect the interpretation of the 'startsector' and
'numsectors' parameters in users' /etc/cryptmount/cmtab files, I think
it safest to incorporate this fix into the next release of cryptmount
rather than an updated version of the 4.1 series. I've updated the
documentation to make clear that these parameters will in future refer
exclusively to 512-byte sectors.
I've just released an alpha version of cryptmount-4.2 on
www.sourceforge.net/projects/cryptmount, which I hope will behave
correctly on optical media.
Kind regards,
RW Penney
+-- on Mon, Feb 28, 2011 at 02:42:01PM +, Paul Martin wrote: ---+
Package: cryptmount
Version: 4.1-2
Severity: important
Tags: patch
When using optical media (sector size 2048 bytes), cryptmount guesses
the device size as a quarter of its actual size.
Index: cryptmount-4.1/cryptmount.c
===
--- cryptmount-4.1.orig/cryptmount.c 2011-02-28 14:20:50.867166060 +
+++ cryptmount-4.1/cryptmount.c 2011-02-28 14:21:24.236073480 +
@@ -196,9 +196,8 @@
if (fd 0) return (int64_t)-1;
#ifdef BLKGETSIZE64
-if (ioctl(fd, BLKGETSIZE64, count) == 0
- ioctl(fd, BLKSSZGET, blklen) == 0) {
-count /= (int64_t)blklen;
+if (ioctl(fd, BLKGETSIZE64, count) == 0) {
+count /= 512;
} else {
count = -1;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562680: installing cryptmount in chroot woes
Hello Harri, Thanks for flagging this issue with cryptmount chroot. As per previous correspondence on bug#551533, I don't think this causes failure of cryptmount's postinst script, but merely leads to modprobe reporting that is was unable to run successfully. Based on a recipe within the udev package, I've drafted a patch which should avoid even this warning message. Perhaps you could try this patch, and let me know whether it represents an acceptable solution? Regards, RW Penney +-- on Sat, Dec 26, 2009 at 10:34:19PM +0100, Harald Dunkel wrote: ---+ Package: cryptmount Version: 4.0.2-1 Severity: important Trying to update cryptount within a chroot (on an external disk) fails with: : Setting up cryptmount (4.0.2-1) ... Installing new version of config file /etc/init.d/cryptmount ... FATAL: Could not load /lib/modules/2.6.32.2/modules.dep: No such file or directory Of course there is no kernel 2.6.32.2 in the chroot installed, but the official Debian kernel. The postinst script should not look at the the output of uname. Regards Harri diff -Nuar cryptmount-4.0.2/debian/postinst cryptmount-patched/debian/postinst --- cryptmount-4.0.2/debian/postinst 2009-08-07 05:52:53.0 +0100 +++ cryptmount-patched/debian/postinst 2010-01-10 14:09:56.0 + @@ -19,9 +19,14 @@ case $1 in configure) - update-rc.d cryptmount-early start 26 S . stop 59 0 6 . /dev/null - update-rc.d cryptmount defaults 28 /dev/null - modprobe -q -a dm-mod dm-crypt || true +update-rc.d cryptmount-early start 26 S . stop 59 0 6 . /dev/null +update-rc.d cryptmount defaults 28 /dev/null + +if [ -r /proc/1/root -a /proc/1/root/ -ef /proc/self/root/ ]; then +modprobe -q -a dm-mod dm-crypt || true +else +echo A chroot environment has been detected - not running 'modprobe dm-crypt' +fi ;; abort-upgrade|abort-remove|abort-deconfigure)
Bug#558347: cryptmount init script should unmount and deconfigure all known encryptedfilesystems at shutdown
Hello Vefa, Thanks for your bug report, and for your helpful patch. I'll make sure your patch is included in future releases of cryptmount, and hope that you will remain a mostly happy cryptmount user at least until then. Kind regards, RW Penney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551533: installing cryptmount in chroot failed
Harri, Thanks for your bug-report. It's not clear that this is a bug in cryptmount, and it likely that the problems you're having are very dependent on the details of your 'chroot' filesystem. It would appear that the absence of the '/lib/modules/...' files within your chroot filesystem is confusing the cryptmount postinst script, probably when it calls 'modprobe'. Clearly, it is not cryptmount's responsibility to setup /lib/modules/...' directly. Before I investigate further, could you give details about how you have setup your chroot filesystem? RW Penney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546502: cryptmount: Incorrect dependencies in init.d script
Hello Petter, Thank you for finding this bug in cryptmount's init.d scripts, and for your helpful patches. I have now merged your patches (with minor modifications to the dependency on $syslog) to create a new upstream version, 4.0.1, which should now be available at http://www.sourceforge.net/projects/cryptmount I have asked my Debian sponsor to upload this to the Debian servers on my behalf. Thanks, RW Penney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529566: cryptmount: cannot handle equal mark when setting mount option like uid=1000
Hello Ryo,
Could you check that you are using fsoptions=uid=1000
rather than opts=... in your /etc/cryptmount/cmtab?
I've had a quick look at the parser within cryptmount-4.0
and can't see any obvious reasons why using fsoptions with a parameter
that includes an equals sign shouldn't work. I've also tried a test
on my installation of cryptmount-4.0, which produced no parser complaints.
If you can try with the fsoptions used as specified in
the cmtab manual-page, and give me a few more details about *how* that fails
(e.g. parser failure, mount failure, mount options not correctly applied, etc.)
that would be very helpful.
Thanks,
RW Penney
+-- on Wed, May 20, 2009 at 04:10:05PM +0900, Ryo IGARASHI wrote: ---+
Package: cryptmount
Version: 4.0-1
Severity: normal
Hi,
I found that I cannot set mount option which has equal mark inside.
I don't dig into the code yet, but it seems that the problem
arises from the option parser.
For example, neither setting /etc/cryptmount/cmtab as
LUKS {
keyformat=luks
dev=/home/XXX/luks.vol
keyfile=/home/XXX/luks.vol
cipher=aes-cbc-plain
dir=/home/xxx/luks
fstype=vfat
opt=uid=1000
}
nor
opt=uid=1000
worked.
I want to share this volume file even in the Windows world using
FreeOTFEExplorer so that I must use vfat for the filesystem.
--
Ryo IGARASHI, Ph.D.
rigar...@gmail.com
-- System Information:
Debian Release: squeeze/sid
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cryptmount depends on:
ii libc62.9-12 GNU C Library: Shared libraries
ii libdevmapper1.02.1 [libdevma 2:1.02.30-3 The Linux Kernel Device Mapper
use
ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime
libr
ii libuuid1 1.41.5-1universally unique id library
cryptmount recommends no packages.
Versions of packages cryptmount suggests:
ii dmsetup 2:1.02.30-3 The Linux Kernel Device Mapper
use
ii openssl 0.9.8g-16 Secure Socket Layer (SSL) binary
a
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516922: cryptmount: Resolved?
Hi Dan, Could you check that you are using cryptmount-3.1.2, which still hasn't entered the 'testing' release yet? (Only 3.1.1 is in 'testing' as of 16th March.) Running 'cryptmount --version' should confirm this. I've just re-run cryptmount's 'mudslinger' testing routings from version 3.1.2 on my (virtualized) Debian-testing installation, and found that it seems to cope perfectly with using the 'blowfish' cipher in libgcyppt-1.4.4-2, and other tests related to OpenSSL compatibility that also use blowfish from libgcrypt seem to work fine. If you really need to access your filesystem urgently, you could try compiling other recent releases of cryptmount from source, as released via http://www.sourceforge.net/projects/cryptmount. If you really want to downgrade, perhaps you could try version 3.0.2. All recent releases, 3.0.2, 3.1.2 and 4.0beta1 should contain the same fix for the libgcrypt-initialization issue. I'd really welcome any clues if additional fixing is needed. Thanks, RWP +-- on Sun, Mar 15, 2009 at 10:16:46PM +0100, Dan H. wrote: ---+ Package: cryptmount Version: 3.1.1-1 Followup-For: Bug #516922 reportbug shows this bug as resolved; however, on my freshly-updated testing box it isn't. This is bad because I need to access some encrypted filesystems. Can I somehow downgrade cryptmount? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cryptmount depends on: ii libc62.9-4 GNU C Library: Shared libraries ii libdevmapper1.02.1 [libdevma 2:1.02.27-4 The Linux Kernel Device Mapper use ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime libr ii libuuid1 1.41.3-1universally unique id library cryptmount recommends no packages. Versions of packages cryptmount suggests: ii dmsetup 2:1.02.27-4 The Linux Kernel Device Mapper use ii openssl 0.9.8g-15 Secure Socket Layer (SSL) binary a -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516922: cryptmount: couldn't find libgcrypt cipher blowfish
This is pretty easy to fix with a call to gcry_check_version() within
kmgrcy_init_algs().
I've attached a patch that should be a temporary fix for version 3.1.1.
I'm in the process of preparing an updated release (3.1.2), together with an
improved version 4.0.
RWP
+-- on Tue, Feb 24, 2009 at 04:19:39PM +0100, Agustin Martin wrote: ---+
reassign 516922 cryptmount
found 516922 3.1.1-1
thanks
On Tue, Feb 24, 2009 at 03:36:21PM +0100, Werner Koch wrote:
On Tue, 24 Feb 2009 15:09, agustin.mar...@hispalinux.es said:
Last libgcrypt11 seems to have added a problem regarding cryptmount.
Since I
Cryptmount does not properly initialize Libgcrypt. From the NEWS file:
...
Please fix Cryptmout.
Thanks a lot for the really quick reply.
Reassigning to cryptmount alone and setting found version.
--
Agustin
diff -Nuar cryptmount-3.1.1/armour-gcry.c cryptmount-3.1.1-patched/armour-gcry.c
--- cryptmount-3.1.1/armour-gcry.c 2008-10-03 12:39:16.0 +0100
+++ cryptmount-3.1.1-patched/armour-gcry.c 2009-02-24 20:18:34.0 +
@@ -384,7 +384,8 @@
static int kmgcry_init_algs()
{
-/* Nothing needed */
+(void)gcry_check_version(NULL); /* Initializes library as side-effect */
+
return 0;
}
Bug#479682: cryptmount: Clarification for Debconf string needed
Dear Kai, Many thanks for your email - I would be delighted to support any effort to produce a German localization of cryptmount. As regards the user-%lu string, this is issued when someone tries to unmount a filesystem that was mounted by a different user. The message is supposed to give the numerical user identity (as provided by getuid()). So, only the '%lu' part should be the numerical UID, and a typical output might be 'only user-16 can unmount opaque'. If you do manage to produce a German set of translations, I would be very grateful if you could send me a copy for inclusion future releases of cryptmount. Kind regards, Richard +-- on Tue, May 06, 2008 at 08:31:34AM +0200, Kai Wasserbäch wrote: ---+ Package: cryptmount Version: 2.1-1 Severity: minor Tags: l10n Hello, during the discussion of the German translation of your Debconf template I came accross the following line: #: cryptmount.c:453 #, c-format msgid only user-%lu can unmount \%s\\n It is unclear whether the »user-« part is also part of the user id or only the replaced part (%lu). After checking the French translation and having a (very) short look into the source code, I'm of the opinion that only the part after the hyphen is the actual uid, but it is not clear. If the whole thing would be the uid, then I shouldn't translate the »user-«. If only the part after the hyphen is the actual uid, then I should (and can) translate it (in which case I would get rid of the hyphen). Please add a comment for translators or change the string to make it more clear what is meant (e.g. by adding quotes). Thank you in advance. Kind regards, Kai Wasserbäch -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: [EMAIL PROTECTED] Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2fingerprint=onhash=onop=vindex) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436676: cryptmount: not handling nostrip build option (policy 10.1) sid/i386
Hello Julien, Thanks for your suggestion about cryptmount. I'm not convinced that this is a problem with either the upstream package, or with the debian build. I can find no reference to any strip/ld -s/install -s in the upstream package; an ordinary make install of the upstream package does not strip the executable; and my debian/rules file does already contain 'dh_strip' in the binary-arch target. Could you possibly give me some more information about where within the cryptmount package you believe the fault might lie? Thanks, Richard +-- on Wed, Aug 08, 2007 at 03:13:22PM +0200, Julien Danjou wrote: ---+ Package: cryptmount Version: 2.1-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: nostrip Hello, There was a problem while autobuilding your package with DEB_BUILD_OPTIONS=nostrip. Final binaries are still stripped. If you call dh_strip correctly in debian/rules, this may mean that upstream is stripping anyway. You should look for call to strip, ld -s or install -s which may strip binaries. Automatic build of cryptmount_2.1-1 on octave for sid/i386 by rebuildd 0.2.1 Build started at 2007-08-08 12:56:41.875112 ** Reading package lists... Building dependency tree... Reading state information... Need to get 262kB of source archives. Get:1 http://ftp.fr.debian.org sid/main cryptmount 2.1-1 (dsc) [659B] Get:2 http://ftp.fr.debian.org sid/main cryptmount 2.1-1 (tar) [246kB] Get:3 http://ftp.fr.debian.org sid/main cryptmount 2.1-1 (diff) [15.1kB] Fetched 262kB in 0s (451kB/s) Download complete and in download only mode W: /home/staff/jd/.pbuilderrc does not exist I: using fakeroot in build. Current time: Wed Aug 8 12:56:46 UTC 2007 pbuilder-time-stamp: 1186577806 Building the build Environment - extracting base tarball [/var/cache/pbuilder/sid.tgz] - creating local configuration - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - policy-rc.d already exists Obtaining the cached apt archive contents Installing the build-deps - Attempting to parse the build-deps - Considering build-dep debhelper (= 4.0.0) - Trying debhelper - Considering build-dep autotools-dev - Trying autotools-dev - Considering build-dep libdevmapper-dev - Trying libdevmapper-dev - Considering build-dep libssl-dev (= 0.9.7) - Trying libssl-dev - Considering build-dep libgcrypt11-dev (= 1.1) - Trying libgcrypt11-dev - Installing debhelper autotools-dev libdevmapper-dev libssl-dev libgcrypt11-dev Reading package lists... Building dependency tree... Reading state information... The following extra packages will be installed: file gettext gettext-base html2text intltool-debian libgpg-error-dev libmagic1 libssl0.9.8 po-debconf zlib1g-dev Suggested packages: dh-make cvs gettext-doc libgcrypt11-doc Recommended packages: curl wget lynx libmail-sendmail-perl libcompress-zlib-perl The following NEW packages will be installed: autotools-dev debhelper file gettext gettext-base html2text intltool-debian libdevmapper-dev libgcrypt11-dev libgpg-error-dev libmagic1 libssl-dev libssl0.9.8 po-debconf zlib1g-dev 0 upgraded, 15 newly installed, 0 to remove and 0 not upgraded. Need to get 63.9kB/8882kB of archives. After unpacking 24.3MB of additional disk space will be used. Get:1 http://ftp.fr.debian.org sid/main libdevmapper-dev 2:1.02.20-2 [63.9kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 63.9kB in 0s (195kB/s) Selecting previously deselected package libssl0.9.8. (Reading database ... 8965 files and directories currently installed.) Unpacking libssl0.9.8 (from .../libssl0.9.8_0.9.8e-5_i386.deb) ... Selecting previously deselected package libmagic1. Unpacking libmagic1 (from .../libmagic1_4.21-2_i386.deb) ... Selecting previously deselected package file. Unpacking file (from .../archives/file_4.21-2_i386.deb) ... Selecting previously deselected package gettext-base. Unpacking gettext-base (from .../gettext-base_0.16.1-2_i386.deb) ... Selecting previously deselected package autotools-dev. Unpacking autotools-dev (from .../autotools-dev_20070306.1_all.deb) ... Selecting previously deselected package html2text. Unpacking html2text (from .../html2text_1.3.2a-3_i386.deb) ... Selecting previously deselected package gettext. Unpacking gettext (from .../gettext_0.16.1-2_i386.deb) ... Selecting previously deselected package intltool-debian. Unpacking intltool-debian (from .../intltool-debian_0.35.0+20060710.1_all.deb) ... Selecting previously deselected package po-debconf. Unpacking po-debconf (from .../po-debconf_1.0.9_all.deb) ... Selecting previously deselected package debhelper. Unpacking debhelper
Bug#420066: Cryptmount loop devices can prevent root from being umounted on shutdown
Hi Carl, Thanks for your bug report. This is indeed a sensible feature request, and your suggested fix is a workable solution. My slight reservation is that 'cryptmount -ua' will only deal with targets that are listed in /etc/cryptmount/cmtab (ignoring any created via the --config-fd option), and will complain about targets that weren't mounted at all. I'll have a think about whether there's any neater way of getting round the issue you've identified. This may have to wait for a future (?minor) release of the upstream package. Thanks, RW Penney +-- on Thu, Apr 19, 2007 at 02:50:55PM -0400, Carl Banks wrote: ---+ Package: cryptmount Version: 1.2-1 Hi: this is a wishlist item. I use cryptmount with a loopback drive that is NOT automounted at boot (that is, it is not listed in /etc/default/cryptmount). I manually mount and umount it as necessary. However, the Debian shutdown scripts fail to umount it, which in turn prevents the root partition from being umounted, which in turn causes an fsck on the next boot. Perhaps it's a bug in initscripts. Regardless, it'd be nice if /etc/init.d/cryptmount could optionally run cryptmount -u -a to umount any manually mounted cryptmounts, or at least allow for targets that are automatically umounted though not automatically mounted. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385157: cryptmount: Bashism in init script
Erich,
Thanks for reporting the non-compliances in cryptmount's init-script,
and for your helpful patch. I've incorporated your patch and tried to
make the script more LSB compliant in its support for the 'status'
argument and in its return-codes.
Before I issue a revised version of the cryptmount Debian
package, I'd be very grateful if you had any comments on the attached
version of the script.
As regards your nautilus/pmount question, I'm afraid I don't use
either of these, so I'm afraid I can't offer you any quick answers there.
Thanks,
Richard
+-- on Tue, Aug 29, 2006 at 03:23:25PM +0200, Erich Schubert wrote: ---+
Package: cryptmount
Version: 1.1-1
Severity: serious
Tags: patch
Justification: Policy 10.4
/etc/init.d/cryptmount: 16: source: not found
/etc/init.d/cryptmount: 19: Syntax error: ( unexpected
Please use POSIX shell (s/source/./; s/^function //;) or specify
/bin/bash as interpreter. A patch to fix the init script is attached;
but I didn't check the other scripts for similar problems.
Maybe you could make the init-script LSB compliant, too.
Btw, do you have a hint for me on how to have nautilus/pmount ask for
the luks passphrase with a graphical prompt?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17.7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages cryptmount depends on:
ii libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii libdevmapper1.02 [libdevmapp 2:1.02.08-1 The Linux Kernel Device Mapper
use
ii libssl0.9.8 0.9.8b-2SSL shared libraries
ii openssl 0.9.8b-2Secure Socket Layer (SSL) binary
a
Versions of packages cryptmount recommends:
ii dmsetup 2:1.02.08-1 The Linux Kernel Device Mapper
use
-- no debconf information
--- /tmp/cryptmount 2006-08-29 15:17:51.0 +0200
+++ /etc/init.d/cryptmount2006-08-29 15:18:21.0 +0200
@@ -12,11 +12,11 @@
test -x ${CM_EXE} || exit 0
if [ -f /etc/default/cryptmount ]; then
-source /etc/default/cryptmount
+. /etc/default/cryptmount
fi
-function configured() {
+configured() {
# check if any of the targets needed at boot has been configured:
for target in ${CM_BOOTDV} ${CM_BOOTFS} ${CM_BOOTSW}; do
if [ -b ${DMPATH}/${target} ]; then
@@ -28,7 +28,7 @@
}
-function dodevices() {
+dodevices() {
case $1 in
start) test -z ${CM_BOOTDV} || ${CM_EXE} --prepare ${CM_BOOTDV}
;;
@@ -38,7 +38,7 @@
}
-function doswaps() {
+doswaps() {
case $1 in
start) test -z ${CM_BOOTSW} || ${CM_EXE} --swapon ${CM_BOOTSW}
;;
@@ -48,7 +48,7 @@
}
-function dofilesys() {
+dofilesys() {
case $1 in
start) test -z ${CM_BOOTFS} || ${CM_EXE} --mount ${CM_BOOTFS}
;;
@@ -58,7 +58,7 @@
}
-function doALL() {
+doALL() {
case $1 in
start)
dodevices start
#!/bin/sh
# boot-time init script for cryptmount
# $Revision: 119 $, $Date: 2006-08-14 17:05:02 +0100 (Mon, 14 Aug 2006) $
# RW Penney, August 2006
CM_EXE=/usr/bin/cryptmount
DMPATH=/dev/mapper
CM_BOOTDV=
CM_BOOTSW=
CM_BOOTFS=
test -x ${CM_EXE} || exit 5
if [ -f /etc/default/cryptmount ]; then
. /etc/default/cryptmount
fi
configured() {
# check if any of the targets needed at boot has been configured:
for target in ${CM_BOOTDV} ${CM_BOOTFS} ${CM_BOOTSW}; do
if [ -b ${DMPATH}/${target} ]; then
true
return
fi
done
false
}
dodevices() {
case $1 in
start) test -z ${CM_BOOTDV} || ${CM_EXE} --prepare ${CM_BOOTDV}
;;
stop) test -z ${CM_BOOTDV} || ${CM_EXE} --release ${CM_BOOTDV}
;;
esac
}
doswaps() {
case $1 in
start) test -z ${CM_BOOTSW} || ${CM_EXE} --swapon ${CM_BOOTSW}
;;
stop) test -z ${CM_BOOTSW} || ${CM_EXE} --swapoff ${CM_BOOTSW}
;;
esac
}
dofilesys() {
case $1 in
start) test -z ${CM_BOOTFS} || ${CM_EXE} --mount ${CM_BOOTFS}
;;
stop) test -z ${CM_BOOTFS} || ${CM_EXE} --unmount ${CM_BOOTFS}
;;
esac
}
doALL() {
case $1 in
start)
dodevices start
doswaps start
dofilesys start
;;
stop)
dofilesys stop
doswaps stop
dodevices stop
;;
esac
}
case $1 in
start)
if configured; then
echo cryptmount auto-filesystems seem to be already configured
else
echo Starting cryptmount targets (hit shift/ctrl if short of
entropy):
Bug#375008: ITP: cryptmount - user-mode mounting of dm-crypt filesystems
Package: wnpp Version: 1.0 Severity: wishlist I would like to propose the package 'cryptmount' (version 1.0.1) for inclusion in the debian distributions. cryptmount is a utility for on-demand user-mode mounting of encrypted filesystems based on the device-mapper (dm-crypt) infrastructure of the 2.6 kernel series. cryptmount also assists the system administrator in setting-up new encrypted filesystems, e.g. through automatic key generation. cryptmount is licensed under the GPL v2 (with an exemption for linkage against the OpenSSL library). Debian-specific sources are available via http://www.pianofaulty.org.uk/software/software.html The packages have been checked with lintian linda and are clean apart from the necessary presence of a setuid binary. (The package is also listed on SourceForge Freshmeat.) Thanks, RW Penney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
