• 0 Posts
  • 57 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2023

help-circle

  • ShortFuse@lemmy.worldtoTechnology@lemmy.worldThe Copilot Delusion
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    8
    ·
    2 months ago

    This is a trash take.

    I just wrote the ability to take a DX9 game, stealthy convert it to DX9Ex, remap all the incompatibility commands so it works, proxy the swapchain texture, setup a shared handle for that proxy texture, create a DX11 swapchain, read that proxy into DX11, and output it in true, native HDR.

    All with the assistance of CoPilot chat to help make sense of the documentation and CoPilot generation and autocomplete to help setup the code.

    All in one day.


  • Definitely not. NoJS is not better for accessibility. It’s worse.

    You need to set the ARIA states over JS. Believe me, I’ve written an entire component library with this in mind. I thought that NoJS would be better, having a HTML and CSS core and adding on JS after. Then for my second rewrite, I made it JS first and it’s all around better for accessibility. Without JS you’d be leaning into a slew of hacks that just make accessibility suffer. It’s neat to make those NoJS components, but you have to hijack checkbox or radio buttons in ways not intended to work.

    The needs of those with disabilities far outweigh the needs of those who want a no script environment.

    While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.

    Also no. You cannot check accessibility with HTML tags alone. Full stop. You need to check the ARIA tags manually. You need to ensure states are updated. You need to add custom JS to handle key events to ensure your components work as suggested by the ARIA Practices page. Relying on native components is not enough. They get you somewhere there, but you’ll also run into incomplete native components that don’t work as expected (eg: Safari and touch events don’t work the same as Chrome and Firefox).

    The sad thing is that accessibility testing is still rather poor. Chrome has the best way to automate testing against the accessibility tree, but it’s still hit or miss at times. It’s worse with Firefox and Safari. You need to doubly confirm with manual testing to ensure the ARIA states are reported correctly. Even with attributes set correctly there’s no guarantee it’ll be handled properly by browsers.

    I have a list of bugs still not fixed by browsers but at least have written my workarounds for them and they are required JS to work as expected and have proper accessibility.

    Good news is that we were able to stop the Playwright devs from adopting this poor approach of relying on HTML only for ARIA testing and now can take accessibility tree snapshots based on realtime JS values.







  • I have just dumped code into a Chrome console and saved a cert while in a pinch. It’s not best practices of course, but when you need something fast for one-time use, it’s nice to have something immediately available.

    You could make your own webpage that works in the browser (no backend) and make a cert. I haven’t published anything publicly because you really shouldn’t dump private keys in unknown websites, but nothing is stopping you from making your own.





  • Don’t use JSON for the response unless you include the response header to specify it’s application/json. You’re better off with regular plaintext unless the request header Accept asked for JSON and you respond with the right header.

    That also means you can send a response based on what the request asked for.

    403 Forbidden (not Unauthorized) is usually enough most of the time. Most of those errors are not meant for consumption by an application because it’s rare for 4xx codes to have a contract. They tend to go to a log and output for human readers later, so I’d lean on text as default.




  • I just recently started working with ImGui. Rewrite compiled game engines to add support for HDR into games that never supported it? Sure, easy. I can mod most games in an hour if not minutes.

    Make the UI respond like any modern flexible-width UI in the past 15 years? It’s still taking me days. All of the ImGui documentation is hidden behind closed GitHub issues. Like, the expected user experience is to bash your head against something for hours, then submit your very specific issue and wait for the author to tell you what to do if you’re lucky, or link to another issue that vaguely resembles your issue.

    I know some projects, WhatWG for one, follow the convention of, if something is unclear in the documentation, the issue does not get closed until that documentation gets updated so there’s no longer any ambiguity or lack of clarity.



  • ShortFuse@lemmy.worldtolinuxmemes@lemmy.world-----BEGIN PRIVATE KEY-----
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Yeah, except for the first few bytes. PKCS8 has some initial header information, but most of it is the OCTET_STRING of the private key itself.

    The PEM (human “readable”) version is Base64, so you can craft up a string and make that your key. DER is that converted to binary again:

    /**
     * @see https://datatracker.ietf.org/doc/html/rfc5208#section-5
     * @see https://datatracker.ietf.org/doc/html/rfc2313#section-11
     * Unwraps PKCS8 Container for internal key (RSA or EC)
     * @param {string|Uint8Array} pkcs8
     * @param {string} [checkOID]
     * @return {Uint8Array} DER
     */
    export function privateKeyFromPrivateKeyInformation(pkcs8, checkOID) {
      const der = derFromPrivateKeyInformation(pkcs8);
      const [
        [privateKeyInfoType, [
          [versionType, version],
          algorithmIdentifierTuple,
          privateKeyTuple,
        ]],
      ] = decodeDER(der);
      if (privateKeyInfoType !== 'SEQUENCE') throw new Error('Invalid PKCS8');
      if (versionType !== 'INTEGER') throw new Error('Invalid PKCS8');
      if (version !== 0) throw new Error('Unsupported PKCS8 Version');
      const [algorithmIdentifierType, algorithmIdentifierValues] = algorithmIdentifierTuple;
      if (algorithmIdentifierType !== 'SEQUENCE') throw new Error('Invalid PKCS8');
      const [privateKeyType, privateKey] = privateKeyTuple;
      if (privateKeyType !== 'OCTET_STRING') throw new Error('Invalid PKCS8');
      if (checkOID) {
        for (const [type, value] of algorithmIdentifierValues) {
          if (type === 'OBJECT_IDENTIFIER' && value === checkOID) {
            return privateKey;
          }
        }
        return null; // Not an error, just doesn't match
      }
    
      return privateKey;
    }
    

    I wrote a “plain English” library in Javascript to demystify all the magic of Let’s Encrypt, ACME, and all those certificates. (Also to spin up my own certs in NodeJS/Chrome).

    https://github.com/clshortfuse/acmejs/blob/96fcbe089f0f949f9eb6830ed2d7bc257ea8dc32/utils/certificate/privateKeyInformation.js#L40

    Edit: To be specific, PKCS8 is usually a PKCS1 (RSA) key with some wrapping to identify it (the OID). The integers (BigInts) you pick for RSA would have to line up in some way, but I would think it’s doable. At worst there is maybe a character or two of garbage at the breakpoints for the RSA integers. And if you account for which ones are absent in the public key, then anybody reading it could get a kick out of reading your public certificate.



  • There is no section 15 or 16 in GPLv3, but I did find section 7 saying:

    Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or

    But that’s an optional thing that you must add onto the GPLv3 license. I’ll have to keep that in mind for the future.

    That would explain why what I’ve read mentioned it’s not guaranteed in GPLv3 (when comparing to MIT). I’ll have to figure out what that notice would look like.