Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 10/04/22 in all areas

  1. https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens
  2. Lars Fosdal

    New security requirements for code signing, disruptive ?

    DaaS - Dongles as a Service
  3. Vincent Parrett

    New security requirements for code signing, disruptive ?

    Blogged - https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens
  4. Vincent Parrett

    New security requirements for code signing, disruptive ?

    Yup, have to a gree, and it doesn't help that the sites that sell certificates are just plain sh1te - I've never seem so much unhelpful content in one place. Working on a blog post about this, hoping to get it out tonight (it's almost 8pm here) or tomorrow. I'm trying to edit it down to a reasonable size and reduce the jargon where possible.
  5. Vincent Parrett

    New security requirements for code signing, disruptive ?

    I didn't have any issues with that last time.. but that was 3 yrs ago. I'm sure these dongles will be a nice little earner for thales and the CA's - the cost of certificates is already outrageous without the added expense of the dongle. CA's say the cost is for the time spent validating the applicants - my guess is much of that is automated - and they have minimum wage call centers doing the rest. License to print money.
  6. Vincent Parrett

    New security requirements for code signing, disruptive ?

    Good luck doing that when your build process runs from a windows service where you are not logged in.
  7. Bill Meyer

    New security requirements for code signing, disruptive ?

    Documentation? That's so 20th century. 😉
  8. Yes. TRegistry has never supported REG_MULTI_SZ in any capacity. No read/write methods, no copy/move semantics, nothing. I don't know why, it's been around like forever. Same with REG_QWORD, too. Correct. Which is weird that they waste effort turning the reported data type id into an enum just to turn it back into a data type id immediately afterwards. If they just used the original data type id as-is, there would be no problem. Yes, it could be fixed. It is not just you. https://quality.embarcadero.com/browse/RSP-15275 Yes, you can, actually. Until Embarcadero fixes it properly, you could simply modify the implementation (not the interface) of the System.Win.Registry.pas file (ie, to make TRegistry.MoveKey() not use TRegistry.GetData() since it doesn't report the types correctly), and then add that modified unit to your projects. The compiler will then use your modified unit instead of the original. Note that this only works if you are NOT compiling with Runtime Packages enabled, though.
×