Re: [DNG] Openvpn CVE fix in devuan chimaera
> On 25 Jul 2022, at 02:21, Mark Hindley wrote: > > Tom, > > On Mon, Jul 25, 2022 at 02:09:34AM +1000, wirelessd...@gmail.com wrote: >>> I have just had a quick look and the commit seems to backport easily. New >>> version for chimaera-security is en route. >>> >>> Mark >> >> Thanks for the quick update! > > 2.5.1-3+devuan2 is now in chimaera-security and will propagate through > amprolla > to the mirrors over the next few hours. Perhaps you could test it and verify > there are no regressions? > > Thanks. > > Mark Thanks Mark, I’m setting up openvpn for the first time so it may take a while before I have a usable configuration for testing the new version. Hopefully someone else on this list is able to verify the changes before I get to it. Tom ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openvpn CVE fix in devuan chimaera
Tom, On Mon, Jul 25, 2022 at 02:09:34AM +1000, wirelessd...@gmail.com wrote: > > I have just had a quick look and the commit seems to backport easily. New > > version for chimaera-security is en route. > > > > Mark > > Thanks for the quick update! 2.5.1-3+devuan2 is now in chimaera-security and will propagate through amprolla to the mirrors over the next few hours. Perhaps you could test it and verify there are no regressions? Thanks. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openvpn CVE fix in devuan chimaera
> On 25 Jul 2022, at 01:51, Mark Hindley wrote: > On Sun, Jul 24, 2022 at 04:19:39PM +0100, Mark Hindley wrote: >> Hi, >> >> On Mon, Jul 25, 2022 at 12:46:09AM +1000, wirelessduck--- via Dng wrote: >>> I saw https://bugs.debian.org/1008015 on the Debian BTS which mentions >>> it was found in openvpn/2.5.1-3, openvpn/2.5.5-1 and fixed in >>> openvpn/2.5.6-1. >>> Devuan chimaera still has openvpn/2.5.1-3+devuan1. Debian bullseye is >>> also still showing openvpn/2.5.1-3 on packages.debian.org/openvpn. >>> How can I check to see if this patch has been applied to the devuan >>> package? >> >> It hasn't, because it hasn't been backported, only fixed upstream in 2.5.6 >> and 2.4.12. >> It might be possible to do, but is considered a low-priority in Debian[1] and >> doesn't have a DSA. > > I have just had a quick look and the commit seems to backport easily. New > version for chimaera-security is en route. > > Mark Thanks for the quick update! Apologies for not noticing this before I sent the previous message. I’ll see if I can request the same fix in Debian bullseye so we don’t need to keep the extra patch in Devuan. Tom ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openvpn CVE fix in devuan chimaera
> On 25 Jul 2022, at 01:19, Mark Hindley wrote: > > Hi, > >> On Mon, Jul 25, 2022 at 12:46:09AM +1000, wirelessduck--- via Dng wrote: >> I saw https://bugs.debian.org/1008015 on the Debian BTS which mentions >> it was found in openvpn/2.5.1-3, openvpn/2.5.5-1 and fixed in >> openvpn/2.5.6-1. >> >> Devuan chimaera still has openvpn/2.5.1-3+devuan1. Debian bullseye is >> also still showing openvpn/2.5.1-3 on packages.debian.org/openvpn. >> >> How can I check to see if this patch has been applied to the devuan >> package? > > It hasn't, because it hasn't been backported, only fixed upstream in 2.5.6 > and 2.4.12. > It might be possible to do, but is considered a low-priority in Debian[1] and > doesn't have a DSA. From my reading of the bug it seems to only affect cases where multiple auth plugins are used together? I would agree that sounds low priority and unlikely to be used in most setups. >> Also, where do I look to see the differences between debian and devuan >> packages? I checked git.devuan.org in the suites/unstable branch of >> devuan/openvpn but that just looks like merge from Debian without any >> extra patches applied. > > That branch is the correct place. If you run > > git diff debian/master..suites/unstable > > you will get the changes. > > Mark > > [1] https://tracker.debian.org/pkg/openvpn Thanks for that Mark. Noted for future reference. -- Tom ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openvpn CVE fix in devuan chimaera
On Sun, Jul 24, 2022 at 04:19:39PM +0100, Mark Hindley wrote: > Hi, > > On Mon, Jul 25, 2022 at 12:46:09AM +1000, wirelessduck--- via Dng wrote: > >I saw https://bugs.debian.org/1008015 on the Debian BTS which mentions > >it was found in openvpn/2.5.1-3, openvpn/2.5.5-1 and fixed in > >openvpn/2.5.6-1. > > > >Devuan chimaera still has openvpn/2.5.1-3+devuan1. Debian bullseye is > >also still showing openvpn/2.5.1-3 on packages.debian.org/openvpn. > > > >How can I check to see if this patch has been applied to the devuan > >package? > > It hasn't, because it hasn't been backported, only fixed upstream in 2.5.6 > and 2.4.12. > It might be possible to do, but is considered a low-priority in Debian[1] and > doesn't have a DSA. I have just had a quick look and the commit seems to backport easily. New version for chimaera-security is en route. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Openvpn CVE fix in devuan chimaera
Hi, On Mon, Jul 25, 2022 at 12:46:09AM +1000, wirelessduck--- via Dng wrote: >I saw https://bugs.debian.org/1008015 on the Debian BTS which mentions >it was found in openvpn/2.5.1-3, openvpn/2.5.5-1 and fixed in >openvpn/2.5.6-1. > >Devuan chimaera still has openvpn/2.5.1-3+devuan1. Debian bullseye is >also still showing openvpn/2.5.1-3 on packages.debian.org/openvpn. > >How can I check to see if this patch has been applied to the devuan >package? It hasn't, because it hasn't been backported, only fixed upstream in 2.5.6 and 2.4.12. It might be possible to do, but is considered a low-priority in Debian[1] and doesn't have a DSA. >Also, where do I look to see the differences between debian and devuan >packages? I checked git.devuan.org in the suites/unstable branch of >devuan/openvpn but that just looks like merge from Debian without any >extra patches applied. That branch is the correct place. If you run git diff debian/master..suites/unstable you will get the changes. Mark [1] https://tracker.debian.org/pkg/openvpn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Openvpn CVE fix in devuan chimaera
Hi, I saw https://bugs.debian.org/1008015 on the Debian BTS which mentions it was found in openvpn/2.5.1-3, openvpn/2.5.5-1 and fixed in openvpn/2.5.6-1. Devuan chimaera still has openvpn/2.5.1-3+devuan1. Debian bullseye is also still showing openvpn/2.5.1-3 on packages.debian.org/openvpn. How can I check to see if this patch has been applied to the devuan package? Also, where do I look to see the differences between debian and devuan packages? I checked git.devuan.org in the suites/unstable branch of devuan/openvpn but that just looks like merge from Debian without any extra patches applied. -- Tom___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI, software RAID1, LVM and encryption
On Sunday 24 July 2022 at 11:58:01, Olaf Meeuwissen wrote: > Hi Antony, > > Thanks for the feedback. I've been researching a bit myself in the mean > time as well but still value additional input from the list. I completely agree - asking people with experience, and with whom you can have a bit of a dialogue, is always a bit more encouranging than finding informatin of random ageas from random people on the Internet :) > > The only part of this you need to remember to do manually is grub-install > > /dev/thing2 if there's ever a new version of grub itself. > > I vaguely recall reading that you could enter a list of space separated > devices to install GRUB to in the installer. True, you can do this in the installer, but if grub gets updated later on, my experience is that it only updates the boot loader on the primary disk. > > Er, what's ESP? > > It's not Extra-Sensory Perception in this context :-P > It's the EFI System Partition and is what gets mounted on /boot/efi/. Ah, right, I seriously doubt you can put that on Raid, because it's not being read by Linux - it's being read by the UEFI/Bios ystsem itself in the machine, in order to find the boot loader (as far as I understand this process). However, I also think it's something that you would simply install on both disksk and then leave it thre - either disk can then get the machien going. > > >- if not, how do I keep the copies in sync? As far as *that* one goes, I don't think you need to - I don't think this ever gets updated. > > > - do I need a separate partition for /boot? > > > > You do not need one, but you can have one. > > Then I'd rather do without. I asked because on a few of my systems it > *is* a separate partition. Yes, it used to be necessary before Linux could find /boot in LVM on Raid, for example. You could put that separate /boot on Raid, but the LVM bit in the middle confused Grub before 2.00, as I recall. > Thinking about that, I believe these were installed to use a "fully" > encrypted system, i.e. the partition mounted on / encrypted as well. In > that case it makes sense because most BIOSs probably do not handle that. It's not the Bios that's doing anything at this stage - it's Grub. Bios looks at the boot sector on the disk, discovers Grub, and hands control over to it. Grub then needs to know where / how to find /boot, because that contains /boot/grub/grub.cfg, which has all the details of everything want to be able to start up. But, the Grub loader in the boot sector is small and simple, and also needs to be able to find an encryption key if it's going to be able to decipher /boot in an encrypted file system. > If I only want/need an encrypted /home then I should be okay with /boot > on the partition that's mounted on /. Precisely. > > > - does randomizing the partition for /home make sense if on LVM and may > > >get resized sometime in the future? > > > > What do you mean by randomizing? > > Writing random data to the partition before using it. This is supposed > to make it harder to decrypt for prying eyes. Ah, right. > After I sent my mail, I thought I could randomize the whole disk (or > that part that's used as an LVM PV) but that might take a while ... Well, let's just think about that - if you write random data to a device and then use it as a PV for a VG, anyone who can get into the LVM system can see the VG and whatever LVs it contains, and therefore just ignores the random data. Unless you can put LVM2 onto an encrypted block device (?), then I don't think this helps you. All you can do is create a VG (that's visible to anyone who can get this far into your machine) and then create an encrypted FS on it. However, as you may have worked out, this is beyond my eperience of setting things up - I do LVM on RAID all the time (both RAID 1 and RAID5), but I've never bothered to set up an encrypted file system. I'm sure others can offer expertise here :) > Thanks again and looking forward to other opinions and follow-up! Indeed - I hope other people chip in with different opinions and expertise of doing things outside my habits. Antony. -- When you find yourself arguing with an idiot, you should first of all make sure that the other person isn't doing the same thing. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI, software RAID1, LVM and encryption
Hi Antony, Thanks for the feedback. I've been researching a bit myself in the mean time as well but still value additional input from the list. Antony Stone writes: > On Sunday 24 July 2022 at 05:18:47, Olaf Meeuwissen via Dng wrote: > >> Hi list, >> >> I lost the single SSD on my mini PC and am in the process of rethinking >> its storage. So far, I've got myself two brand new and identical PCIe >> NVMe SSDs (256GB) for use in a software RAID1 setup. I think I need to >> enable UEFI to get access to the BIOS from the GRUB menu. >> >> I want my /home directory on a partition of its own, at a minimum, and >> encrypt it. I don't see a need to encrypt much else as I am not after >> plausible deniability. It's mostly to be able to return a broken disk >> for a replacement and still sleep in relative peace of mind ;-) >> >> I haven't quite made up my mind as to a need for other partitions. I >> use containers and VMs quite a bit. Perhaps these are better stored >> some place other than the partitions for / or (an encrypted) /home. >> >> With 64GB of RAM, I don't see much need for swap. If needed, I could >> always add a swapfile instead of a partition. >> >> Given the above, >> >> - what are your expert(?) opinions on partitioning for this? > > Use LVM on top of RAID - great flexibility, plus reliability. > >> - how do I make (and keep) both disks bootable? > > grub-install /dev/thing1 > grub-install /dev/thing2 > > You can keep /boot as a separate RAID1 (separate from LVM, that is) if you > want to, or you can include it in LVM these days. > > That means you have the grub loader itself, the grub.conf, and the initramfs > and kernel, all replicated on both disks. > > The only part of this you need to remember to do manually is grub-install > /dev/thing2 if there's ever a new version of grub itself. I vaguely recall reading that you could enter a list of space separated devices to install GRUB to in the installer. On top of that, I think I actually configured something like that in /etc/default/grub on one of the machines at the office. >> - can I put the ESP on RAID1? > > Er, what's ESP? It's not Extra-Sensory Perception in this context :-P It's the EFI System Partition and is what gets mounted on /boot/efi/. >>- if not, how do I keep the copies in sync? > >> - do I need a separate partition for /boot? > > You do not need one, but you can have one. Then I'd rather do without. I asked because on a few of my systems it *is* a separate partition. Thinking about that, I believe these were installed to use a "fully" encrypted system, i.e. the partition mounted on / encrypted as well. In that case it makes sense because most BIOSs probably do not handle that. If I only want/need an encrypted /home then I should be okay with /boot on the partition that's mounted on /. >>- if so, can it be put on RAID1? > > Yes. > >> - if not, how do I keep the copies in sync? > > n/a ACK. >> - should I use LVM? > > Yes, IMHO. > >> - does randomizing the partition for /home make sense if on LVM and may >>get resized sometime in the future? > > What do you mean by randomizing? Writing random data to the partition before using it. This is supposed to make it harder to decrypt for prying eyes. After I sent my mail, I thought I could randomize the whole disk (or that part that's used as an LVM PV) but that might take a while ... Thanks again and looking forward to other opinions and follow-up! -- Olaf Meeuwissen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI, software RAID1, LVM and encryption
On Sunday 24 July 2022 at 05:18:47, Olaf Meeuwissen via Dng wrote: > Hi list, > > I lost the single SSD on my mini PC and am in the process of rethinking > its storage. So far, I've got myself two brand new and identical PCIe > NVMe SSDs (256GB) for use in a software RAID1 setup. I think I need to > enable UEFI to get access to the BIOS from the GRUB menu. > > I want my /home directory on a partition of its own, at a minimum, and > encrypt it. I don't see a need to encrypt much else as I am not after > plausible deniability. It's mostly to be able to return a broken disk > for a replacement and still sleep in relative peace of mind ;-) > > I haven't quite made up my mind as to a need for other partitions. I > use containers and VMs quite a bit. Perhaps these are better stored > some place other than the partitions for / or (an encrypted) /home. > > With 64GB of RAM, I don't see much need for swap. If needed, I could > always add a swapfile instead of a partition. > > Given the above, > > - what are your expert(?) opinions on partitioning for this? Use LVM on top of RAID - great flexibility, plus reliability. > - how do I make (and keep) both disks bootable? grub-install /dev/thing1 grub-install /dev/thing2 You can keep /boot as a separate RAID1 (separate from LVM, that is) if you want to, or you can include it in LVM these days. That means you have the grub loader itself, the grub.conf, and the initramfs and kernel, all replicated on both disks. The only part of this you need to remember to do manually is grub-install /dev/thing2 if there's ever a new version of grub itself. > - can I put the ESP on RAID1? Er, what's ESP? >- if not, how do I keep the copies in sync? > - do I need a separate partition for /boot? You do not need one, but you can have one. >- if so, can it be put on RAID1? Yes. > - if not, how do I keep the copies in sync? n/a > - should I use LVM? Yes, IMHO. > - does randomizing the partition for /home make sense if on LVM and may >get resized sometime in the future? What do you mean by randomizing? Antony. -- Too many people spend money they haven't earned to buy things they don't want, to impress people they don't like. - Will Rogers Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
