secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

«‹›942 »

MononcQc: May 29, 2007

Raymond T. Racing posted:

that's absolutely true, but I think it's unheard of for a CA to know that they're mis-issuing certs, then continue to issue them until being called out by everyone in the community

oh yeah that part smells like bullshit for sure.

# ? Apr 19, 2024 20:49

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 15:46

spankmeister: Jun 15, 2008

MononcQc posted:

To play stick in the mud by coming in with incident theory talk, if you have a policy and find it is never respected, then you have to wonder if the policy actually is realistic and practical to implement. I'm not saying Entrust is in the right here, but that if what you find in aggregate is that pretty much no one meets the policy properly, then the problem isn't necessarily that everyone fails while the policy is correct; it might be that the expectations and consequences of the revocations do clash with what the policy wishes the world were like when it isn't.

I don't actually know any of these numbers because I've only read this thread and not any of the other stuff. If we find that pretty much only a few CAs constantly fail with these things while others succeed (which is different from "not failing by never exercising the policy"), then yeah the policy might be fine and corrective action on the CA required. If it's 50-50 you also gotta wonder if there's any population-level distinction that could be in play: what is the difference between the context of those who succeed and those who don't, aside from their lack of adherence to rules?

But for all the normative "you gotta follow the rules" approaches, there's always a real risk that said rules are based on an inaccurate or impractical view of the world and that can't be successfully met predictably.

yes but on the same token if the policy is important but just hard or expensive to follow, but you don't enforce the policy by punishing non-compliance there's no incentive to follow them either.

# ? Apr 19, 2024 20:51

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

MononcQc posted:

To play stick in the mud by coming in with incident theory talk, if you have a policy and find it is never respected, then you have to wonder if the policy actually is realistic and practical to implement. I'm not saying Entrust is in the right here, but that if what you find in aggregate is that pretty much no one meets the policy properly, then the problem isn't necessarily that everyone fails while the policy is correct; it might be that the expectations and consequences of the revocations do clash with what the policy wishes the world were like when it isn't.

I don't actually know any of these numbers because I've only read this thread and not any of the other stuff. If we find that pretty much only a few CAs constantly fail with these things while others succeed (which is different from "not failing by never exercising the policy"), then yeah the policy might be fine and corrective action on the CA required. If it's 50-50 you also gotta wonder if there's any population-level distinction that could be in play: what is the difference between the context of those who succeed and those who don't, aside from their lack of adherence to rules?

But for all the normative "you gotta follow the rules" approaches, there's always a real risk that said rules are based on an inaccurate or impractical view of the world and that can't be successfully met predictably.

I think there's also a difference between finding out that you can't fulfill your obligations (however onerous or realistic those may be) and then a) going to the root programs for a special dispensation, or b) coming to bugzilla telling everyone that you don't give a poo poo and the browsers can just deal with it.

e: like, it seems pretty pointless to me to revoke and reissue with the exact same content, but I suspect that the roots would be more amenable to letting that slide if entrust hadn't from the start said they weren't going to comply with anything. see also: the LE issue where a bunch of their certs were issued with a validity period of one too many second

Bonfire Lit fucked around with this message at 21:04 on Apr 19, 2024

# ? Apr 19, 2024 21:01

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

the whole "doing gently caress-all until the Big Swinging Dick came into the room" doesn't help much either

# ? Apr 19, 2024 21:28

Main Paineframe: Oct 27, 2010

MononcQc posted:

To play stick in the mud by coming in with incident theory talk, if you have a policy and find it is never respected, then you have to wonder if the policy actually is realistic and practical to implement. I'm not saying Entrust is in the right here, but that if what you find in aggregate is that pretty much no one meets the policy properly, then the problem isn't necessarily that everyone fails while the policy is correct; it might be that the expectations and consequences of the revocations do clash with what the policy wishes the world were like when it isn't.

I don't actually know any of these numbers because I've only read this thread and not any of the other stuff. If we find that pretty much only a few CAs constantly fail with these things while others succeed (which is different from "not failing by never exercising the policy"), then yeah the policy might be fine and corrective action on the CA required. If it's 50-50 you also gotta wonder if there's any population-level distinction that could be in play: what is the difference between the context of those who succeed and those who don't, aside from their lack of adherence to rules?

But for all the normative "you gotta follow the rules" approaches, there's always a real risk that said rules are based on an inaccurate or impractical view of the world and that can't be successfully met predictably.

as i understand it, the problem here is that there are policy requires companies to inconvenience paying customers for the benefit of non-customers

even if it's practical to implement the policy, companies are still going to be reluctant to follow it unless there's an incentive attached that's strong enough to overcome the power of "we don't want to go tell our paying customers that they have to do some extra work because we hosed up their certs"

# ? Apr 19, 2024 21:33

fluppet: Feb 10, 2009

But it wasn't that long ago another CA hosed around and found out that they no longer exist

# ? Apr 19, 2024 21:44

Shame Boy: Mar 2, 2010

Main Paineframe posted:

as i understand it, the problem here is that there are policy requires companies to inconvenience paying customers for the benefit of non-customers

initially it sounded like that (and that was their stated excuse) but more and more it's starting to look like entrust just literally does not have a mechanism that is capable of doing this sort of thing, they'd have to build one first, and I guess they just never thought they'd actually have to do it??

MononcQc i know you love you some complex systems and processes analysis (and i love you for that) but in this case i think it's just "entrust is actually just real incompetent and nobody's called them out on it until now." which i mean, i guess there's a change to the process that could be made to find out what other CA's are also actually just three kids in a trenchcoat or whatever.

e: actually wait that last bit i think is more or less what you were getting at anyway, with the added caveat of "if a bunch fail the test then maybe the rules need to be reconsidered" and yeah ok that's a good point

Shame Boy fucked around with this message at 22:17 on Apr 19, 2024

# ? Apr 19, 2024 22:13

Shame Boy: Mar 2, 2010

Captain Foo posted:

the whole "doing gently caress-all until the Big Swinging Dick came into the room" doesn't help much either

also this, i think this is definitely what really riled everyone up

# ? Apr 19, 2024 22:15

SeaborneClink: Aug 27, 2010; MAWP... MAWP!

Let's figure out a way to rub a little shamir's secret sharing into the mix to allow a quorum of other CAs to revoke certs issued by a misbehaving CA if not dealt with in a timely manner.

Edit: also knowing the companies on that cert list, I assure you that not a single one of them when receiving the email from entrust saying, "hey we did a little oopsy woopsy and need to give you a new cert, we're supposed to have these all revoked by EOW but we'll give you a month or more if you tell us you need more time..."

Not a single one of those companies was going to say "oh, okay I see this is certificate related, we'll actually have all of them done by tomorrow, thanks for the heads up!"

SeaborneClink fucked around with this message at 23:04 on Apr 19, 2024

# ? Apr 19, 2024 22:57

Wiggly Wayne DDS: Sep 11, 2010

Shame Boy posted:

initially it sounded like that (and that was their stated excuse) but more and more it's starting to look like entrust just literally does not have a mechanism that is capable of doing this sort of thing, they'd have to build one first, and I guess they just never thought they'd actually have to do it??

i'm still not sure if they have the capacity for revoke and reissue in practice, nevermind the lack of any business rationale to ever do it

warning: this is just me rambling and looking at some data mainly, if you have CA experience you'll be more versed in noticing if something's off

i was curious and did a bunch of work over the past few days building off of the Entrust: CPS typographical (text placement) error's issue of 6008 certs

if you've never done it before - it's actually really annoying to get a list of sha256 of certs back into their serial form to check against a certificate revocation list. keep in mind a year ago i was part of cloning a chunk of imgur and did that trivially, this took over 20 hours of scraping crt.sh slowly (i investigated far more methods, and short of bothering someone at a root program to get me the data this is what'd work)

but anyway about Entrust's L1K, crt.sh atm tells us:

code:

Population	Unexpired
Certs		22479
Precerts	489196
Total		511675

so there's half a million live certs out there, 3m+ expired but generally entrust hands off pre-certs as they should

now i do some cursed data analysis (warning, google sheet sucks) in a way that it's presentable and works in most places. here's a viewable version (published html) you want the CRL_Activity_Plot and CRL_Acitivity_Graph tabs

this is CRL data going back to 2024-03-12, a date chosen as it's 1 day before entrust's more recent issues all started happening. so you'd think the CRL would be very active, no?

11287 revocations in just over a month, never peaking over 500/day. you can see they work monday-friday and have an automated job running at 4am utc to either push the revoked certs to the crl, or just to revoke them. on the full data i took notice of the 'key compromise' reason, and of the 63 times it's happened only 12 were not at 04:00:00. you'd think those would be pushed to the crl as a priority.

anyway for half a million certs and their issues in the past month you'd think they'd be a bit more active. i count 42882 certs they've listed in various problems the past month with distinct crt.sh sha256sums, but this could be bloated with mistagged precert vs final cert (on the bugzilla side to be clear)

so i analysed those 6008 certs and hit a couple of snags. one is that 35 of the certs were actually made on L1F instead of L1K, but they're still reported as OV correctly. the other is that 14 of the certs aren't logged on crt.sh at all[1]. i doubt this is an ingest issue as they were submitted quite a while ago...

the other was that when putting together all of this i was missing 42 certs.. which turns out to be they were given 28 and 30 byte serial numbers instead of 32 like every other cert (why? i don't know. one was revoked though and appears on the crl that way so i know it's .. intended)

as a reminder the CPS update was 03-22, and noticed 03-26 so these are certificates generated in that 5-day window. now this does look suspicious at first glance, and having only a tiny snapshot of revocations to look at the sample showed activity that looked like entrust internally revoking as a reaction. but march 25th and 26th are monday and tuesday, and from the above we know they barely revoke at a weekend

additionally when i was looking at these certs i noticed some oddities that i won't link. such as vmware certs that would be issued then revoked 7s later, and not just a couple - but i didn't go and compile all that data and it's kinda irrelevant

this is mostly just me rambling anyway, i don't have an outcome to this other than .. does this seem like regular CA activity in response to multiple revocation/reissue incidents? seems like business as usual to me

[1] 14 certs assigned to L1F (quoted so you can collapse it and it won't be included in further quotes):

quote:

https://crt.sh/?sha256=1086E495E6D4CDC926CDFE3C3F083272D70BE65F3BF75336393C6975A11E6D8A
https://crt.sh/?sha256=125E7D5030D1B4C57DFF13DAD4E9525024DEC3649F77745C906C229765E24F5F
https://crt.sh/?sha256=4323087C85F6FB5F7F2D8E66D9C5EC8BC4007D37CBF93ACC159D6173D0793AFA
https://crt.sh/?sha256=637D768E1D386ACDEBED435C84B0B08C2C6B09B840045A34503DB518645657B5
https://crt.sh/?sha256=692991CF2926851395CE4C15A37AC4B6AD13D46979E5A7912F39FDD9FFFAC4A9
https://crt.sh/?sha256=749109CEAEE9CF2D88E6999D4768697696E7C67E4C4DB2648A19137A5D1669ED
https://crt.sh/?sha256=76ADEF1237C4B07652D8A597337580947E6B6E1A83F3D25332BE3863BA180CAC
https://crt.sh/?sha256=7DD2FF3533BD7C64DEA51E89F469EDD29B007C5DC4708597A9F0594B76954EE1
https://crt.sh/?sha256=AF4274B727520335A80F82C0E615EFB87D37C5F03971AFDF9114ACBCFA5882EA
https://crt.sh/?sha256=C5E3974E1DBE2A36450B662A6867988B31361F9DFC67AC4ACA38B386B43432F5
https://crt.sh/?sha256=EF5F20F6B5913C3A5F9477E2BE2D6801D85DD80B9BB42A5363AA3B1E82566FD9
https://crt.sh/?sha256=F5455CBE0B50EC0002A5C1F83AC49CC38842B30D84B830D8A23257AEFA406117
https://crt.sh/?sha256=F7F70E1FD16BB7B09A21486AAC9295CFD8259BB1C6EF363D5A61C1230B1E9426
https://crt.sh/?sha256=FE5BEA6F8D4333CFEFA3277AC2F4D544987FFF7C3ED83514EAF92A34919F19E6

Wiggly Wayne DDS fucked around with this message at 23:51 on Apr 19, 2024

# ? Apr 19, 2024 23:34

Raymond T. Racing: Jun 11, 2019

wayne don�t burn yourself out but god drat does this just keep getting weirder and seemingly more incompetent

# ? Apr 19, 2024 23:46

MononcQc: May 29, 2007

Shame Boy posted:

initially it sounded like that (and that was their stated excuse) but more and more it's starting to look like entrust just literally does not have a mechanism that is capable of doing this sort of thing, they'd have to build one first, and I guess they just never thought they'd actually have to do it??

MononcQc i know you love you some complex systems and processes analysis (and i love you for that) but in this case i think it's just "entrust is actually just real incompetent and nobody's called them out on it until now." which i mean, i guess there's a change to the process that could be made to find out what other CA's are also actually just three kids in a trenchcoat or whatever.

e: actually wait that last bit i think is more or less what you were getting at anyway, with the added caveat of "if a bunch fail the test then maybe the rules need to be reconsidered" and yeah ok that's a good point

yeah it�s just that over the last few pages, unless I misunderstood by reading too fast, a few other non-Entrust CAs were shown as having issues doing timely revocations around the 1-5 day period I saw quoted.

and so that suggested to me that even though entrust appears to have its own pattern of apparent disregard of policies (including their own!) deserving sanctions, many other CAs may find themselves showing similar issues adhering to specific parts of quick revocation (to limit impact, because of holidays, etc).

so this triggers a part of me that goes �there might be something here�. If the policy is actually adequate and the problem is too many people not complying, then yeah proactive probing could make sense (if practical); if the rationales given behind delays do make sense (eg. don�t want to shut down a hospital�s system), then the policy could need adjusting and complexification.

in some ways, choosing to apply or not to apply sanctions on incidents on a case by case basis is adequately adding flexibility to the policy and maybe it�s all fine.

but all of this is me from the sidelines with way too little information, just drawing on incident spider sense.

# ? Apr 20, 2024 01:05

shackleford: Sep 4, 2006

stack rank the CA's by number and severity of incidents and every year kick out the worst CA imo

the CA's would hire up all the world's best cert touchers and point them at their competitors

# ? Apr 20, 2024 01:20

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

require that the board and c-suite put their money in a trust that is protected by their own cert somehow

# ? Apr 20, 2024 01:27

Methylethylaldehyde: Oct 23, 2004; BAKA BAKA

fluppet posted:

But it wasn't that long ago another CA hosed around and found out that they no longer exist

Which one was this? I wasn't able to find anything other than the Chinese registrar one.

# ? Apr 20, 2024 02:48

redleader: Aug 18, 2005; Engage according to operational parameters

Captain Foo posted:

the reg stuff was a good intro but i want mooooooreeee

# ? Apr 20, 2024 04:08

NFX: Jun 2, 2008; Fun Shoe

Wiggly Wayne DDS posted:

i'm still not sure if they have the capacity for revoke and reissue in practice, nevermind the lack of any business rationale to ever do it

warning: this is just me rambling and looking at some data mainly, if you have CA experience you'll be more versed in noticing if something's off

i was curious and did a bunch of work over the past few days building off of the Entrust: CPS typographical (text placement) error's issue of 6008 certs

if you've never done it before - it's actually really annoying to get a list of sha256 of certs back into their serial form to check against a certificate revocation list. keep in mind a year ago i was part of cloning a chunk of imgur and did that trivially, this took over 20 hours of scraping crt.sh slowly (i investigated far more methods, and short of bothering someone at a root program to get me the data this is what'd work)

but anyway about Entrust's L1K, crt.sh atm tells us:
code:
Population	Unexpired
Certs		22479
Precerts	489196
Total		511675
so there's half a million live certs out there, 3m+ expired but generally entrust hands off pre-certs as they should

now i do some cursed data analysis (warning, google sheet sucks) in a way that it's presentable and works in most places. here's a viewable version (published html) you want the CRL_Activity_Plot and CRL_Acitivity_Graph tabs

this is CRL data going back to 2024-03-12, a date chosen as it's 1 day before entrust's more recent issues all started happening. so you'd think the CRL would be very active, no?

11287 revocations in just over a month, never peaking over 500/day. you can see they work monday-friday and have an automated job running at 4am utc to either push the revoked certs to the crl, or just to revoke them. on the full data i took notice of the 'key compromise' reason, and of the 63 times it's happened only 12 were not at 04:00:00. you'd think those would be pushed to the crl as a priority.

anyway for half a million certs and their issues in the past month you'd think they'd be a bit more active. i count 42882 certs they've listed in various problems the past month with distinct crt.sh sha256sums, but this could be bloated with mistagged precert vs final cert (on the bugzilla side to be clear)

so i analysed those 6008 certs and hit a couple of snags. one is that 35 of the certs were actually made on L1F instead of L1K, but they're still reported as OV correctly. the other is that 14 of the certs aren't logged on crt.sh at all[1]. i doubt this is an ingest issue as they were submitted quite a while ago...

the other was that when putting together all of this i was missing 42 certs.. which turns out to be they were given 28 and 30 byte serial numbers instead of 32 like every other cert (why? i don't know. one was revoked though and appears on the crl that way so i know it's .. intended)

as a reminder the CPS update was 03-22, and noticed 03-26 so these are certificates generated in that 5-day window. now this does look suspicious at first glance, and having only a tiny snapshot of revocations to look at the sample showed activity that looked like entrust internally revoking as a reaction. but march 25th and 26th are monday and tuesday, and from the above we know they barely revoke at a weekend

additionally when i was looking at these certs i noticed some oddities that i won't link. such as vmware certs that would be issued then revoked 7s later, and not just a couple - but i didn't go and compile all that data and it's kinda irrelevant

this is mostly just me rambling anyway, i don't have an outcome to this other than .. does this seem like regular CA activity in response to multiple revocation/reissue incidents? seems like business as usual to me

[1] 14 certs assigned to L1F (quoted so you can collapse it and it won't be included in further quotes):

precerts can still make you transparent

# ? Apr 20, 2024 06:51

fluppet: Feb 10, 2009

Methylethylaldehyde posted:

Which one was this? I wasn't able to find anything other than the Chinese registrar one.

It was Trustcor https://www.theregister.com/2022/12/02/mozilla_microsoft_trustcor/ but that was a little more than failing to revoke

# ? Apr 20, 2024 07:20

shackleford: Sep 4, 2006

Methylethylaldehyde posted:

Which one was this? I wasn't able to find anything other than the Chinese registrar one.

https://wiki.mozilla.org/CA/Symantec_Issues

# ? Apr 20, 2024 07:44

Wiggly Wayne DDS: Sep 11, 2010

NFX posted:

precerts can still make you transparent

? i'm aware. it's the preferred method as you give a poison-flagged cert over that browsers won't trust. it's why i mentioned:

quote:

generally entrust hands off pre-certs as they should

shackleford posted:

https://wiki.mozilla.org/CA/Symantec_Issues

and while nothing's happened yet... https://wiki.mozilla.org/CA/Camerfirma_Issues

# ? Apr 20, 2024 12:28

infernal machines: Oct 11, 2012; we monitor many frequencies. we listen always. came a voice, out of the babel of tongues, speaking to us. it played us a mighty dub.

shackleford posted:

https://wiki.mozilla.org/CA/Symantec_Issues

this is the one that came to mind initially

# ? Apr 20, 2024 12:36

NFX: Jun 2, 2008; Fun Shoe

Wiggly Wayne DDS posted:

? i'm aware. it's the preferred method as you give a poison-flagged cert over that browsers won't trust. it's why i mentioned:

and while nothing's happened yet... https://wiki.mozilla.org/CA/Camerfirma_Issues

sorry, I was trying to make a pregnancy joke

# ? Apr 20, 2024 16:37

MustardFacial: Jun 20, 2011; George Russel's
Official Something Awful Account
Lifelong Tory Voter

shackleford posted:

stack rank the CA's by number and severity of incidents and every year kick out the worst CA imo

the CA's would hire up all the world's best cert touchers and point them at their competitors

English Premier League, but with CA�s.

# ? Apr 20, 2024 17:29

JAnon: Jul 16, 2023

https://www.404media.co/a-spy-site-is-scraping-discord-and-selling-users-messages/
https://www.404media.co/spy-site-selling-discord-messages-linked-to-kiwi-farms/

(reshare from the tech bubble thread)
failure to make social messaging app actually secure leads to site emerging that scrapes messages and then sells them to doxxing forums

JAnon fucked around with this message at 19:30 on Apr 20, 2024

# ? Apr 20, 2024 19:19

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

JAnon posted:

https://www.404media.co/a-spy-site-is-scraping-discord-and-selling-users-messages/
https://www.404media.co/spy-site-selling-discord-messages-linked-to-kiwi-farms/

(reshare from the tech bubble thread)
failure to make social messaging app actually secure leads to site emerging that scrapes messages and then sells them to federal agencies

more like sells them to kiwifarms. Federal agencies can just subpoena Discord directly

# ? Apr 20, 2024 19:22

Slashrat: Jun 6, 2011; YOSPOS

Why would anyone who isn't internet illiterate have any expectation of privacy regarding their activity in a Discord server where they don't personally know and trust every other member?

# ? Apr 20, 2024 19:30

pseudorandom name: May 6, 2007

Everyone who isn't a Millennial is Internet illiterate.

# ? Apr 20, 2024 19:46

Main Paineframe: Oct 27, 2010

JAnon posted:

https://www.404media.co/a-spy-site-is-scraping-discord-and-selling-users-messages/
https://www.404media.co/spy-site-selling-discord-messages-linked-to-kiwi-farms/

(reshare from the tech bubble thread)
failure to make social messaging app actually secure leads to site emerging that scrapes messages and then sells them to doxxing forums

they're just using a bot to join every big open-to-the-public discord they can find and scrape all the publicly-viewable messages in public channels there

# ? Apr 20, 2024 19:47

Zamujasa: Oct 27, 2010; Bread Liar

Slashrat posted:

Why would anyone who isn't internet illiterate have any expectation of privacy regarding their activity in a Discord server where they don't personally know and trust every other member?

most people do not expect every public location they are in to have someone recording their every move to be sold to one of the shittiest websites on the planet

there's plenty to be said about how discord enables this with infinite message history for everyone who joins, but that doesn't mean this behavior should be seen as normal or good

# ? Apr 20, 2024 19:50

Trabisnikof: Dec 24, 2005

Bonfire Lit posted:

more like sells them to kiwifarms. Federal agencies can just subpoena Discord directly

there's many examples of federal agencies purchasing data from data brokers because they can do so without the same oversight as subpoenas and also sometimes it is cheaper too.

# ? Apr 20, 2024 19:56

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

NFX posted:

sorry, I was trying to make a pregnancy joke

ok i thought i saw this but then i wasn't sure if i was just seeing things

e: lol

# ? Apr 20, 2024 21:40

Grace Baiting: Jul 20, 2012; Audi famam illius;
Cucurrit quaeque
Tetigit destruens.

The Fool posted:

waiting with bated breath for the part 2 on amir's substack

https://webpki.substack.com/p/entrust-considered-harmful-part-2

# ? Apr 23, 2024 02:48

Grace Baiting: Jul 20, 2012; Audi famam illius;
Cucurrit quaeque
Tetigit destruens.

also this

Shame Boy posted:

i mean this 100% sincerely: thank you for taking time out of your real actual important job to join us in our dumb lil' shitposting-about-security thread, this whole ride has been real fascinating

# ? Apr 23, 2024 02:50

Wiggly Wayne DDS: Sep 11, 2010

Grace Baiting posted:

https://webpki.substack.com/p/entrust-considered-harmful-part-2

this is going to be a long ride there's 19 more issues before we get to 2024...

# ? Apr 23, 2024 03:31

Raymond T. Racing: Jun 11, 2019

jesus loving christ, can we just drop the hammer on them at this point

# ? Apr 23, 2024 03:45

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

Raymond T. Racing posted:

jesus loving christ, can we just drop the hammer on them at this point

i believe we are in the "prosecution" phase

# ? Apr 23, 2024 04:46

Raymond T. Racing: Jun 11, 2019

Captain Foo posted:

i believe we are in the "prosecution" phase

I do think it�s suspect we haven�t seen any updates, I bet there�s some back channeling going down right now.

# ? Apr 23, 2024 04:54

Wiggly Wayne DDS: Sep 11, 2010

Raymond T. Racing posted:

I do think it�s suspect we haven�t seen any updates, I bet there�s some back channeling going down right now.

we do get questions dropped by each root program and entrust insisting they'll answer them later. a lot of this is hoping entrust will self-regulate into not shooting themselves in the foot and not being aware this is their m.o for the past 5y+

# ? Apr 23, 2024 04:59

flakeloaf: Feb 26, 2003; Still better than android clock

Captain Foo posted:

i believe we are in the "prosecution" phase

if you told me tomorrow morning my job was to convince a jury of the facts of this case i'd walk into a volcano

# ? Apr 23, 2024 05:00

Adbot: ADBOT LOVES YOU

# ? May 3, 2024 15:46

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

flakeloaf posted:

if you told me tomorrow morning my job was to convince a jury of the facts of this case i'd walk into a volcano

honestly seems a lot easier than figuring out, say, Oracle v Goog

# ? Apr 23, 2024 05:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

«‹›942 »