(ℹ) Join us now at the IRC channel | ䷉ Find the plain text version at this address.
| *asusbox2 (~rianne@host81-154-169-167.range81-154.btcentralplus.com) has joined #boycottnovell | Feb 23 01:37 | |
| *rianne__ has quit (Ping timeout: 272 seconds) | Feb 23 01:38 | |
| *asusbox has quit (Ping timeout: 265 seconds) | Feb 23 01:38 | |
| *rianne__ (~rianne@host81-154-169-167.range81-154.btcentralplus.com) has joined #boycottnovell | Feb 23 01:50 | |
| schestowitz__ | >>> BTW, I've improved the handling of blockquotes conversion into Gemini. | Feb 23 03:19 |
|---|---|---|
| schestowitz__ | >>> It's not feasible to retrofit all the material which is already | Feb 23 03:19 |
| schestowitz__ | >>> converted but new documents will be better. | Feb 23 03:19 |
| schestowitz__ | >> I think that older pages will certainly be accessed less (Nada, Tizen, | Feb 23 03:19 |
| schestowitz__ | >> Novell and other out of date stuff), so if we were ever to regenerate | Feb 23 03:19 |
| schestowitz__ | >> pages I think recently is what matters most. | Feb 23 03:19 |
| schestowitz__ | > I can re-do the recent years next week. I still have the following | Feb 23 03:19 |
| schestowitz__ | > cached, and can redo them at no additional burden: | Feb 23 03:19 |
| schestowitz__ | > | Feb 23 03:19 |
| schestowitz__ | > 2009 2010 2011 2012 2013 2014 2015 | Feb 23 03:19 |
| schestowitz__ | > | Feb 23 03:19 |
| schestowitz__ | > Right now 2008, 2007, and 2006, in that sequence, are downloading in the | Feb 23 03:19 |
| schestowitz__ | > background and will get the improved quoting. | Feb 23 03:19 |
| schestowitz__ | I suppose we could always, at any time, improve what we have without affecting the URL structure. I've just checked again that today's bulletin contains working Gemini URLs. | Feb 23 03:19 |
| schestowitz__ | My dad asked me about Gemini yesterday because he began checking a little more closely what we do. He's not so technical... | Feb 23 03:19 |
| schestowitz__ | >> We once thought about making our site static. Now we're sort of closer | Feb 23 03:19 |
| schestowitz__ | >> to that. | Feb 23 03:19 |
| schestowitz__ | > Yes, I still think static is the way to go. | Feb 23 03:19 |
| schestowitz__ | > | Feb 23 03:19 |
| schestowitz__ | > The comments are a question though. If they are third party, that is | Feb 23 03:19 |
| schestowitz__ | > less good even if the third party is the Fediverse or similar. | Feb 23 03:19 |
| schestowitz__ | Comments don't often add much of real substance or importance. | Feb 23 03:19 |
| schestowitz__ | <li> | Feb 23 03:44 |
| schestowitz__ | <h5><a href="https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/">The modern packager’s security nightmare</a></h5> | Feb 23 03:44 |
| -TechrightsBN/#boycottnovell-blogs.gentoo.org | The Council and the Community – Michał Górny | Feb 23 03:44 | |
| schestowitz__ | <blockquote> | Feb 23 03:44 |
| schestowitz__ | <p>n the simplest words, static linking means embedding your program’s dependencies directly into the program image. The term is generally used in contrast to dynamic linking (or dynamic loading) that keep the dependent libraries in separate files that are loaded at program’s startup (or runtime). </p> | Feb 23 03:44 |
| schestowitz__ | <p> Why is static linking bad? The primary problem is that since they become the integral part of the program, they can not be easily replaced by another version. If it turns out that one of the libraries is vulnerable, you have to relink the whole program against the new version. This also implies that you need to have a system that keeps track of what library versions are used in individual programs. </p></ | Feb 23 03:44 |
| schestowitz__ | blockquote></li> | Feb 23 03:44 |
| *TechrightsBN has quit (Ping timeout: 260 seconds) | Feb 23 04:07 | |
| schestowitz__ | <h5><a href="https://mjg59.dreamwidth.org/55845.html">Making hibernation work under Linux Lockdown</a></h5> | Feb 23 04:20 |
| schestowitz__ | <blockquote> | Feb 23 04:20 |
| schestowitz__ | <p>When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we | Feb 23 04:20 |
| schestowitz__ | encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel. </p> | Feb 23 04:20 |
| schestowitz__ | <p> But what if the attacker is able to gain access to the encrypted key? Let's say a kernel bug is hit that prevents hibernation from resuming, and you boot back up without wiping the hibernation image. Root can then read the key from the partition, ask the TPM to decrypt it, and then use that to create a new hibernation image. We probably want to prevent that as well. Fortunately, when you ask the TPM to | Feb 23 04:20 |
| schestowitz__ | encrypt something, you can ask that the TPM only decrypt it if the PCRs have specific values. "Sealing" material to the TPM in this way allows you to block decryption if the system isn't in the desired state. So, we define a policy that says that PCR 23 must have the same value at resume as it did on hibernation. On resume, the kernel resets PCR 23, extends it to the same value it did during hibernation, and then attempts to | Feb 23 04:20 |
| schestowitz__ | decrypt the key. Afterwards, it resets PCR 23 back to the initial value. Even if an attacker gains access to the encrypted copy of the key, the TPM will refuse to decrypt it. </p> | Feb 23 04:21 |
| schestowitz__ | <p> And that's what this patchset implements. There's one fairly significant flaw at the moment, which is simply that an attacker can just reboot into an older kernel that doesn't implement the PCR 23 blocking and set up state by hand. Fortunately, this can be avoided using another aspect of the boot process. When you boot something via UEFI Secure Boot, the signing key used to verify the booted code is | Feb 23 04:21 |
| schestowitz__ | measured into PCR 7 by the system firmware. In the Linux world, the Shim bootloader then measures any additional keys that are used. By either using a new key to tag kernels that have support for the PCR 23 restrictions, or by embedding some additional metadata in the kernel that indicates the presence of this feature and measuring that, we can have a PCR 7 value that verifies that the PCR 23 restrictions are present. We then seal | Feb 23 04:21 |
| schestowitz__ | the key to PCR 7 as well as PCR 23, and if an attacker boots into a kernel that doesn't have this feature the PCR 7 value will be different and the TPM will refuse to decrypt the secret.</p></blockquote></li> | Feb 23 04:21 |
| Techrights-sec2 | the background processing of 2020 finished. it should now have better | Feb 23 15:00 |
| Techrights-sec2 | block quotes | Feb 23 15:00 |
| schestowitz__ | excellent, I will try to be consistent with the html to assure it's consistently converted | Feb 23 15:00 |
| Techrights-sec2 | thanks. there's not really a way to do error checking since it is just scraping | Feb 23 15:36 |
| *TechrightsBN (~b0t@techrights.org) has joined #boycottnovell | Feb 23 16:16 | |
| TechrightsBN | Hello World! I'm TechrightsBN running phIRCe v0.75 | Feb 23 16:16 |
| *TechrightsBN has quit (Ping timeout: 272 seconds) | Feb 23 16:21 | |
| *TechrightsBN (~b0t@techrights.org) has joined #boycottnovell | Feb 23 18:28 | |
| TechrightsBN | Hello World! I'm TechrightsBN running phIRCe v0.75 | Feb 23 18:28 |
| Techrights-sec2 | HV and TR and TM ha | Feb 23 20:10 |
| Techrights-sec2 | ve had network problems and been unavailable on and offhost! | Feb 23 20:10 |
| schestowitz__ | Yes, that happened yesterday as well, it breaks off for a few minutes, kaniini irc clients also temporarily falls offline or stalls | Feb 23 20:11 |
| schestowitz__ | Did I miss anything between 5pm UTC today and this time the session of ytalk resumed? | Feb 23 20:11 |
| Techrights-sec2 | I send a partial traceroute in the e-mail a while ago. #From####################### | Feb 23 20:12 |
| Techrights-sec2 | both the EU and the US the break was in the same point | Feb 23 20:12 |
| Techrights-sec2 | No, just the comments about HV etc being unavialable via the net. | Feb 23 20:13 |
| schestowitz__ | I went to sleep around that time, so did not see the moment ytalk broke apart... could not reconnect until just now | Feb 23 20:14 |
| *schestowitz__ is now known as schestowitz | Feb 23 22:34 | |
| schestowitz | Re: Jonathan Wiltshire image URL change | Feb 23 23:09 |
| schestowitz | > You have a few links to the jonathan-wiltshire-* image in here: | Feb 23 23:09 |
| schestowitz | > | Feb 23 23:09 |
| schestowitz | > http://techrights.org/2020/10/26/jonathan-wiltshire-gchq-theory/ | Feb 23 23:09 |
| schestowitz | > | Feb 23 23:09 |
| schestowitz | > The new URL: | Feb 23 23:09 |
| -TechrightsBN/#boycottnovell-techrights.org | Jonathan Wiltshire and Debian, Falsified Harassment Claims, Tiger Computing and GCHQ | Techrights | Feb 23 23:09 | |
| schestowitz | > | Feb 23 23:09 |
| schestowitz | > https://ipfs.io/ipfs/QmereN1pANAgeiwPZiADehPsNKwrye4qpFB8YhTLqcGNDQ | Feb 23 23:09 |
| schestowitz | Updated. | Feb 23 23:09 |
| schestowitz | > Hi Roy, | Feb 23 23:10 |
| schestowitz | > | Feb 23 23:10 |
| schestowitz | > I made some changes to the text, can you please sync it? I feel the | Feb 23 23:10 |
| schestowitz | > revised text is easier to follow and makes a stronger point. | Feb 23 23:10 |
| schestowitz | I will update now. | Feb 23 23:10 |
| schestowitz | It does add some necessary background, which I sort of overlooked as it lacked an explanation of the analogous scenario. I can think of many other similar stories. | Feb 23 23:14 |
| schestowitz | Re: Bill Gates burned in croatian carnaval | Feb 23 23:41 |
| schestowitz | > https://twitter.com/NicolasPichot6/status/1363280931163938821 | Feb 23 23:41 |
| -TechrightsBN/#boycottnovell-@NicolasPichot6: 🔴Bill Gates ciblé par un Carnaval en Croatie qui a tout compris. Son effigie caricaturale finira brûlée. (voir au d… https://t.co/0qOf8T1qlQ | Feb 23 23:41 | |
| -TechrightsBN/#boycottnovell-@NicolasPichot6: 🔴Bill Gates ciblé par un Carnaval en Croatie qui a tout compris. Son effigie caricaturale finira brûlée. (voir au d… https://t.co/0qOf8T1qlQ | Feb 23 23:41 | |
Generated by irclog2html.py 2.6 | ䷉ find the plain text version at this address.