Fly-by, but HDCP is already cracked. There's no shortage of HDCP strippers from AliExpress; although they use clever marketing terms to avoid spelling out the fact (presumably to avoid legal troubles)
It's being 15 years already
Fly-by, but HDCP is already cracked. There's no shortage of HDCP strippers from AliExpress; although they use clever marketing terms to avoid spelling out the fact (presumably to avoid legal troubles)
It's being 15 years already
Agreed, they should not be using Windows in the first place. That should have been the first line of defense.
> There was a whole host of companies that had zero problems, not because they're using Rust, but because they have much better security practices and quality infosec employees.
Fair enough, I only commented on one layer of the security stack -- so your remark that expands the scope is valid and welcome.
> We're all waiting for your anti-malware Rust Win32 kernel module...
I am done working for free. If I am paid to do it I am sure I would have done better than this poor confused soul who allows NULL pointer dereferencing which is a mistake that most C/C++ interns quickly learn to avoid.
Crowdstrike borked RHEL 1 month ago https://access.redhat.com/solutions/7068083 Literally the same situation, unbootable machines.
The reality is that shitty software broke everything. Why do we have to drag the OS into this?
Cthulhu is definitely less evil than Meta.
If a specific version of TPM becomes required to use future versions of Windows, we will have swappable TPM chips ? Eg update your TPM chip just like you update your GPU :)
Which means importing a whole js file
The standard existed 2016, I did a short stint for a company that was implemented eIDAS back then.
They even have a test suite you can use to check how well you comply with the standard: https://ec.europa.eu/digital-building-blocks/wikis/display/D...
It is very archaic to work with though, but at least they try to have a standard.
The real value in eIDAS would be "unlocked" if they would release a proper API specification with which a digital signatures application would integrate with any EIDAS CA to emit/sign certificates. And then enforce that any eIDAS compliant CA would implement this API.
In practice that means any company/digital signatures product could do a integration with this API once and then be able to use ANY certification authority they want/need/offer best prices for certificates.
Without this API, eIDAS is just a marketing moniker because the power belongs to the selected Certification Authorities. They set the prices, they choose WHOM can integrate with them to isse certificates and there is NO interoperability between them. This doesnt allow for a open market and makes the top players control everything while shouting "standards" and "eIDAS".....
eIDAS was introduced in 2016. Now 7 years later there still isn't a API specification for interoperability (there are drawings though https://blog.eid.as/new-apis-for-the-eidas-ecosystem/ )
In the meantime, any digital signature done in EU must be done with a certificate issued only by the "select" CA to be considered "valid".
I’m the author and owner of a similar code style/code quality package in a fairly large company and went through a very similar process, culminating with writing our own Roslyn-based analyzers to enforce various internal practices to supplant the customized configuration of the Microsoft provided analyzers. Also, we discovered that different projects need different level of analysis. We’re less strict with e.g test projects than core infrastructure. But all projects need to have the same formatting and style. That too can be easily done with one nuget using msbuild.
That's like using a car for "traveling" 3 meters. Why not just use dotnet format + .editorconfig , they were created just for this purpose.