2
<p>they didn't even ask her if she needed help they just kidnapped her <a href="https://neuromatch.social/tags/monsterdon" class="mention hashtag" rel="tag">#<span>monsterdon</span></a></p>
<p><span class="h-card" translate="no"><a href="https://social.vivaldi.net/@pelavarre" class="u-url mention">@<span>pelavarre</span></a></span> oh yeah I remember investigating that doc! at the time I had no context for why it was written that way; thankfully (?) I have never needed to integrate an actual real SCSI device with UMS, only various virtual or semi-virtual ones. I do remember how painful the whole thing was anyway</p>
<p>read that like a wesley willis ad lib, "spooky over london, spooky over chicago" <a href="https://neuromatch.social/tags/monsterdon" class="mention hashtag" rel="tag">#<span>monsterdon</span></a></p>
<p>alright it's fuckin spooky out in LA right now, fuckin spooky in the world right now, let's watch some goddamn huge ants <a href="https://neuromatch.social/tags/monsterdon" class="mention hashtag" rel="tag">#<span>monsterdon</span></a></p>
<p>Root post for <a href="https://social.coop/tags/monsterdon" class="mention hashtag" rel="tag">#<span>monsterdon</span></a></p>
<p>4</p><p>In reality, the clash or agreement in my actual length A vs your expected length E can be spec’d out lots more concisely or lots more verbosely </p><p>Spec’ing 13 Cases gets engineering managers to delegate the work to someone who will get each Corner right</p>
<p>3</p><p>Eventually I wrote the “thirteen cases” into https: // usb . org /sites/default/files/usbmassbulk_10.pdf</p><p>&quot;&quot;&quot;</p><p>6.7 The Thirteen Cases</p><p>This section describes the thirteen possible cases of host expectations and device intent in the absence of overriding error conditions</p><p>Table 6.1 – Host/Device Data Transfer Matrix graphically displays these thirteen cases</p><p>Important notes about the thirteen cases.</p><p>• Cases (1), (6) and (12) represent the majority of host and device transactions. They indicate those conditions where the host and device agree as to the direction and amount of data to be transferred. These cases are also referred to as “the thin diagonal”</p><p>&quot;&quot;&quot;</p><p>=&gt;</p>
<p>1</p><p>I shipped a bug in 1994 where all one byte passwords were accepted as equal</p><p>The root cause was a bug in a SCSI chip that substituted a constant for every one byte payload</p><p>We didn’t test the reject-wrong-password case enough</p><p>2</p><p>&gt; We didn’t test the reject-wrong-password case enough</p><p>And they, and we, didn’t test the one-byte payload case enough</p><p>After this bit me once, forever thereafter I paid more attention to misaligned lengths</p><p>=&gt;</p>
<p>./ <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> </p><p>The &quot;thirteen cases&quot; punchline here interests you, as a leading historian of USB Bulk Only Transport (BOT/BBB != CBI)<br />?</p><p>&gt; &gt; &gt; Okta allowing login bypass for any usernames with 52+ characters</p><p>&gt; &gt; I tend to be sympathetic with coders who introduce bugs, having introduced my share. Getting all the edge cases right can be hard.<br />&gt; &gt; <br />&gt; &gt; But every now and then a bug comes along that makes me think &quot;How in the hell could this have possibly happened?&quot;</p><p>&gt; the bcrypt hash function ignores input above a certain length! so if you do bcrypt(username || password) for some reason, a sufficiently long username will make it accept any password<br />&gt;<br />&gt; to fix this you can sha256 the input first</p><p>=&gt;</p>