Re: Secure Boot dbx Configuration Update
On Sunday, September 25, 2022 4:03:50 PM EDT Ansgar wrote: > On Sun, 2022-09-25 at 11:17 -0700, John Darrah wrote: > > I'm tracking testing and with my most recent update I started getting > > the nag to update the Secure Boot dbx. When I click the graphical > > 'update' button it appears to update something, but the update button > > remains as if nothing changed. > > Some firmware updates, including DBX updates, are distributed via a > different service than apt: fwupd. The fwupdmgr program provides a > command-line interface; the most helpful commands are probably > "fwupdmgr get-updates" (get list of updates, i.e., equivalent to "apt > update"), "fwupdmgr update" (install updates) and "fwupdmgr get- > history" (history of installed firmware updates). I follow exactly this process and get the following error. This started occurring about a week ago. Upgrade available for UEFI dbx from 77 to 217 UEFI dbx and all connected devices may not be usable while updating. Continue with update? [Y|n]: Y Downloading… [***] Decompressing… [***] Authenticating… [***] Authenticating… [***] Updating UEFI dbx… [***] Verifying… [***] Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/ EFI/BOOT/shimx64.efi Authenticode checksum [af79b14064601bc0987d4747af1e914a228c05d622ceda03b7a4f67014fee767] is present in dbx I believe the error is due to the following bug reported in the upstream bug system. https://github.com/fwupd/fwupd/issues/5035 This particular bug doesn't appear in the Debian bugs for the package fwupd. I'm also running stable which has a terribly outdated version of fwupd. I'm on a Lenovo Thinkpad X1. I need to investigate a bit more before filing a bug report. -- JP signature.asc Description: This is a digitally signed message part.
Re: Gmail bounce unauthenticated @debian.org addresses
On Friday, March 4, 2022 12:37:38 PM EST Ansgar wrote: > On Fri, 2022-03-04 at 10:21 -0500, LeJacq, Jean Pierre wrote: > > There are standard best practices for forwarding support in SPF. > > > > http://www.open-spf.org/Best_Practices/Forwarding/ > > Having each individual user have to configure forwarders (i.e., per- > user whitelists), including services like mailing lists, our bug > tracker and so on, seems impractical. I also doubt many mail providers > allow user to do so. I agree. What does make sense if any forwards that the Debian infrastructure uses. > And SRS also relies on whitelists again (otherwise it just allows > bypassing any SPF policy). Again agree, so it's a scaling issue. Again, it makes sense to do for the Debian infrastructure, not necessarily every user. -- JP
Re: Gmail bounce unauthenticated @debian.org addresses
On Friday, March 4, 2022 10:14:09 AM EST Ansgar wrote:
> On Fri, 2022-03-04 at 15:45 +0100, Baptiste Beauplat wrote:
> > However for SPF, if I'm not mistaken, this is not possible for
> > @debian.org addresses since Debian does not offers an MSA and
> > therefor not a single (or enumerable list of) exit point.
>
> Using SPF would be possible. Gentoo does that:
>
> gentoo.org. IN TXT "v=spf1 [...] include:%{l}.%{o}.spf.gentoo.org ?all"
>
> and their users can then add SPF entries for individual localparts.
>
> But either way is quite complicated for "just" using a mail address for
> outgoing mail.
>
> Also some infrastructure in Debian will break DKIM signatures. For
> example, bugs.debian.org (always) and lists.debian.org (sometimes, for
> example when List-* header fields are part of the DKIM signature). So
> one can't rely on valid SPF/DKIM anyway and, as far as I understand,
> rely on debian.org infrastructure being on providers' whitelists
> instead (as it "impersonates" other domains in mail sender addresses).
There are standard best practices for forwarding support in SPF.
http://www.open-spf.org/Best_Practices/Forwarding/
--
JP
Re: Gmail bounce unauthenticated @debian.org addresses
On Friday, March 4, 2022 9:45:21 AM EST Baptiste Beauplat wrote: > On 3/4/22 15:41, LeJacq, Jean Pierre wrote: > > Google uses a number of criteria when blocking. A missing DKIM is just > > one. > > See the referenced document: > > > > https://support.google.com/mail/answer/81126 > > > > One of the problems here is that mentors.debian.net does not have the > > standard email security DNS records - SPF, DKIM, DMARC, MTA-TLS, DANE. > > This doesn't automatically cause Google to classify as spam but we really > > should have these in place to protect email. > > > > As an example, we may be spoofing mentors.debian.net with wv-debian- > > mentors1.wavecloud.de (not 100% clear with the headers provided). SPF > > could > > handle this. > > Indeed we are looking into it for mentors. > > However for SPF, if I'm not mistaken, this is not possible for > @debian.org addresses since Debian does not offers an MSA and therefor > not a single (or enumerable list of) exit point. SPF can handle delegation like this without too much trouble. -- JP
Re: Gmail bounce unauthenticated @debian.org addresses
On Friday, March 4, 2022 9:15:59 AM EST Baptiste Beauplat wrote: > > > >> mentors.debian.net with the following message: > > Can you please share the complete headers of the bounced message? Aka > > the thing in the message/rfc822 part of the DSN message. Right now we > > don't know what they see from your explanation. > > I'm attached the bounce. > > Am I mistaken in thinking that's only a case of simply rejecting > unsigned DKIM email? I've just gone through the process of securing email with Google so I might be able to help a bit. Google uses a number of criteria when blocking. A missing DKIM is just one. See the referenced document: https://support.google.com/mail/answer/81126 One of the problems here is that mentors.debian.net does not have the standard email security DNS records - SPF, DKIM, DMARC, MTA-TLS, DANE. This doesn't automatically cause Google to classify as spam but we really should have these in place to protect email. As an example, we may be spoofing mentors.debian.net with wv-debian- mentors1.wavecloud.de (not 100% clear with the headers provided). SPF could handle this. -- JP signature.asc Description: This is a digitally signed message part.
Key signing at SouthEast LinuxFest
I'm hoping to have my key signed by a Debian Developer at the SouthEast LinuxFest this coming weekend. http://southeastlinuxfest.org/ If there's enough interest, I can setup a BoF meeting for the Debian community at the conference. -- JP
Re: systemd-fsck?
On Saturday 10 May 2014 09:57:25 Marc Haber wrote: On Fri, 09 May 2014 20:30:22 +0200, Michael Biebl wrote: Am 09.05.2014 19:56, schrieb Steve Langasek: I don't think systemd integration is in a state today that this is ready to become the default. What are you missing? For example, keyscript= in /etc/crypttab. I got systemd just by not paying attention, and in result an unbootable system since my crypto setup heavily relies on keyscript=. Thankfully it was only a test VM that got borked that way before I dared touching production. I second this. We had several production systems that became unbootable due to this systemd change. It took quite some time to understand the intricate dependency among packages and we were fortunate to have a reliable recovery mechanism. We still do not understand why systemd does not seem to work with the cryptsetup package. The complexity of systemd is substantially higher which makes debugging these types of issues more difficult. -- JP signature.asc Description: This is a digitally signed message part.
