Re: F41 Change Proposal: Self Encrypting Drives Support in the Installer (self-contained)
With BitLocker the hardware encryption was enabled by default, which is not what is being proposed. Even now it is still possible to configure BitLocker to use hardware encryption. It's up to the user to decide whether the performance benefits are worth trusting the hardware vendor and their proprietary implementation of data encryption. On Fri, Jul 12, 2024 at 6:27 PM Vitaly Zaitsev via devel wrote: > > On 12/07/2024 17:54, Aoife Moloney wrote: > > Add optional support for using native hardware encryption on TCG OPAL2 > > compliant drives when configuring disk encryption in the installer. > > The hardware encryption implementation can't be verified and can't be > trusted[1]. Even Microsoft has switched BitLocker to software > implementation[2]. > > [1] > https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/ > > [2] > https://www.pcworld.com/article/398130/bitlocker-windows-built-in-encryption-tool-no-longer-trusts-your-ssds-hardware-protection.html > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning piper
Taken. On Fri, Jul 7, 2023 at 3:48 AM Peter Hutterer wrote: > > I've orphaned the piper package. This is the GTK GUI to interface with > the libratbag daemon to configure programmable mice. It's up for grabs > now if you want it, first come, first serve and so on. > > My personal take is that this should be flatpak only but who am I to > stand in the way of a motivated packager :) > > Cheers, > Peter > > PS: if you *are* motivated, Piper desparately needs upstream maintainers I'd love to help, but I already neglect too many side projects to make promises. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: libblockdev 3.0 coming to Rawhide
I plan to update libblockdev from 2.28 to 3.0 in Rawhide. This version will include a soname bump and some backwards incompatible API changes. udisks2 is the only package that directly depends on libblockdev, but packages using the Python bindings (python3-blockdev) need to be updated too. $ sudo dnf repoquery --releasever=39 --disablerepo='*' --enablerepo='*-source' --whatrequires libblockdev-devel udisks2-0:2.9.4-6.fc38.src $ sudo dnf repoquery --releasever=39 --whatrequires python3-blockdev anaconda-core-0:39.20-1.fc39.x86_64 python3-blivet-1:3.7.1-4.fc39.noarch targetd-0:0.10.2-1.fc39.noarch Anaconda and targetd already contain changes to make them compatible with both versions of the API and I'll build new versions of blivet and udisks together with libblockdev 3.0 in a side tag. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for new freecol package-maintainer
Thank you. As Hans said, I also didn't have time to update freecol to the latest upstream for some time now so I am really glad someone is willing to take over. Peter, if you want I can transfer the package fully to you and be just a comaintainer. On Wed, Apr 26, 2023 at 2:05 PM Hans de Goede wrote: > > Hi Peter, > > On 4/26/23 13:33, Peter Hanecak wrote: > > Hello, > > > > please pass that to me, I'll try to update and if it goes well, we can keep > > it in the distro. > > That is great, thank you. > > I have added you as a co-admin of the package now, while > doing this I noticed that officially I have already handed > it over to Vojtěch Trefný (vtrefny, added to the Cc) > a while ago. > > But Vojtěch also does not seem to have time to keep this > in sync with upstream, so if you can take care of that, > then that would be great. > > Regards, > > Hans > > > > > > > > On 4/25/23 15:32, Hans de Goede wrote: > >> Hi All, > >> > >> Once upon a time I packaged freecol, a FOSS game inspired by > >> the colonization computergame. > >> > >> Unfortunately I have not been able to make time to properly > >> maintain the package and now it is several versions behind > >> the latest upstream release. > >> > >> As such I think the time has come to hand freecol over > >> to a new maintainer, or remove it from Fedora so that > >> people can install it from flathub instead: > >> https://flathub.org/apps/org.freecol.FreeCol > >> > >> If you can help by taking over freecol, please let me know. > >> > >> Otherwise I'll remove it from Fedora for f38+ in a couple > >> of weeks. > >> > >> Note freecol is written in java. > >> > >> Regards, > >> > >> Hans > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > >> Do not reply to spam, report it: > >> https://pagure.io/fedora-infrastructure/new_issue > >> > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Future of BIOS RAID support in the installer
Hi, I am planning to change how we support BIOS RAID (sometimes also called Firmware or Fake RAID) in the installer in the future. I plan to go through the official Fedora change process for Fedora 38, but I'd like to get some feedback first. We are currently using dmraid to support these types of RAIDs in blivet[1] (storage library the Anaconda installer uses) and we would like to replace it with mdadm. The main reason is that dmraid is no longer actively maintained, but it will also mean one less dependency for the installer (we use mdadm for the software RAID support) and one less service running during boot (dmraid-activation.service). The potential issue here is that mdadm doesn't support all BIOS RAID types. mdadm supports only Common RAID Disk Data Format standard[2] (DDF) and Intel Matrix Storage Technology (IMSM) so by switching to mdadm we would remove support for some of the older formats that existed before DDF was standardized. I am not sure how many people are still using these older RAIDs and the main reason for sending this email is to find out. So if you are using a BIOS RAID on your system, can you check what kind? You can find out simply by checking the filesystem type on the underlying disk(s) reported by for example `lsblk -f`. Types supported by mdadm are "ddf_raid_member" and "isw_raid_member". Types supported only by dmraid are "adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member", "lsi_mega_raid_member", "nvidia_raid_member", "silicon_medley_raid_member" and "via_raid_member". So if you have one of the latter ones and you'd be impacted by this change, please let me know so we can reconsider this change. Note that this would affect only the installation process, I know some external and NAS drives use BIOS RAID and these won't be affected, dmraid is not being removed from the repositories (at least I am not aware of this right now, some distributions are already planning to remove dmraid completely). [1] https://github.com/storaged-project/blivet [2] https://www.snia.org/tech_activities/standards/curr_standards/ddf Regards Vojtech Trefny vtre...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Thu, Jul 28, 2022 at 2:39 PM Chris Adams wrote: > > Once upon a time, Vojtech Trefny said: > > This is also what happens if you choose to "decrypt" your BitLocker > > volume in Windows so if it is this case, cryptsetup doesn't support > > it. We intentionally ignored this case mostly because it looked like a > > small corner case (if you choose do decrypt the volume, Windows will > > in the end fully decrypt the data and get rid of the BitLocker > > volume/container), but if it's going to be a widespread use, we might > > need to start looking into that. As Milan said, a reproducer and an > > upstream issue for cryptsetup would be nice. > > Unfortunately, I don't know a reproducer, other than "buy a Thinkpad". > I don't actually know much about Windows stuff. Ok, I found there is some OEM BitLocker configuration that sounds like it might be it: "BitLocker automatic device encryption starts during Out-of-box (OOBE) experience. However, protection is enabled (armed) only after users sign in with a Microsoft Account or an Azure Active Directory account. Until that, protection is suspended and data is not protected." https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker I'll try to find more and try to figure out how OEM installation works with Windows and see if we can add support for this case to cryptsetup. > -- > Chris Adams > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy wrote: > > > > On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote: > > Once upon a time, Neal Gompa said: > >> My understanding is that Windows preloads are now blank-encrypted. > >> That is, there's a BitLocker volume wrapping the filesystem, even with > >> encryption turned off. It makes encrypting the disk later > >> significantly easier (it doesn't have to do filesystem resizing and > >> reallocation games). > > > > Huh, okay. It seems cryptsetup can't open it, but dislocker can. > > You can do something like > > dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C > > And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I > wouldn't be surprised if it's encrypted, and the encryption key itself isn't > wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can > discover and cryptsetup can't (yet) - but I'm speculating. This is also what happens if you choose to "decrypt" your BitLocker volume in Windows so if it is this case, cryptsetup doesn't support it. We intentionally ignored this case mostly because it looked like a small corner case (if you choose do decrypt the volume, Windows will in the end fully decrypt the data and get rid of the BitLocker volume/container), but if it's going to be a widespread use, we might need to start looking into that. As Milan said, a reproducer and an upstream issue for cryptsetup would be nice. > > > > But this does mean that doing anything in anaconda based on detection of > > BitLocker being present should consider that... > > Either libblkid or cryptsetup would need to learn how to differentiate > between the two kinds of Bitlocker volumes, in order for anaconda to have a > chance of treating them differently. I'm not sure what the consideration > would be though. If it really is the case described above, from libblkid point of view, this is still BitLocker and the data is still encrypted so no difference in how it should be handled -- mount cannot mount it, ntfsresize cannot resize it so for all intents and purposes it is a BitLocker volume and we cannot treat it differently just because the volume key itself is not protected. > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
