Information on the revocation of WinRAR 5.91 digital certificate
rarlab.com
rarlab.com
It's hard to dispute this imo. There are many good reasons certificates should be revoked, but the reasoning should be 100% public information, for both the vendor and users who may have trusted the original certificate.
I'm building a desktop app, and the process to even get a certificate is absurd. Each CA has their own wildly different processes, and seemingly answers to nobody. I changed cert providers recently after Digicert suddenly raised their prices 400% on a whim, and it took a huge number of changing requirements, phone calls, 3rd parties, and over a month to receive the new one, despite already having an existing verified & still-valid signing certificate with all those details from an equally legitimate provider.
I'd kill to see a modern service a la Let's Encrypt but for code signing. Something transparent, reliable, fast & trusted cross-platform (I can dream). Verifying identity is a hard problem, but it's really not _that_ hard a problem - there's plenty of fintech services that can reliably do sufficient KYC for banking in 5 minutes with a few id details and video call.
As long as the CAs do that job (which is a separate issue), it's fine if John Doe can get 50 different CAs to certify that he is, indeed, John Doe.
Here's the most relevant excerpt:
> A CA MUST revoke a Code Signing Certificate in any of the four circumstances: (1) the Application Software Supplier requests revocation, (2) the subscriber requests revocation, , (3) a third party provides information that leads the CA to believe that the certificate is compromised or is being used for Suspect Code, or (4) the CA otherwise decides that the certificate should be revoked.
[0] https://cabforum.org/baseline-requirements-code-signing/
If all you're after is some kind of rate limiting then forget about identity verification and just require proof of a unique $500 donation to a 501(c)(3). Not only would it be easier to automate, it would do some good in the world, and people would be a lot happier to see their resources go there than to some box checking bureaucrats.
My Tucows certificate is still a single *.pfx file - whereas my arguably less-consequential AATL (Adobe PDF signing) certificate is stuck on a crappy USB device that requires me to install marketing-laden software for. I miss my old commodity smartcard-based certificates.
https://www.schneier.com/essays/archives/2005/04/two-factor_...
Your computer is unknowingly infected with malware, you go to do an update to your app, you insert your smartcard and enter your PIN, the malware signs the malware author's thing with it.
That said, the latter part does make this a non-starter, although the same is true of most means of identity verification, which lock out anyone with inadequate identity paperwork.
I get the reasoning of "voter id laws are bad because they disproportionately disenfranchise poor people", but "code signing certificates are bad because they disproportionately disenfranchise poor programmers" doesn't really make any sense. If you know how to program, and you can pony up $300 for the code signing certificate, chances are you probably already have the requisite identity paperwork. On the off chance that you don't, it's no big deal because lots of prominent software aren't signed (eg. 7zip, notepad++), so it's not like you're sticking out by not doing so.
At a sample size of one (me), this is false in 100% of cases. (To be fair, you did say "chances are" rather than "it is certainly the case that".)
> it's no big deal because lots of prominent software aren't signed (eg. 7zip, notepad++)
Sure, but that's a argument against code signing in general, not fees versus paperwork.
To install the certs manually takes a bit of research. I recently wrote a Node.js script to do this in my application cross-OS using a Stackoverflow answer as a reference.
Looking at application development I think a similar thing could be done, but what would we pin identity to? I don't know if there is one thing that every app has like a website.
How about domain name?
Whenever I install (Windows) software I rarely care about the mailing address or D.B.A. name; I look at the website address listed.
I still think that demonstrated control of a domain is sufficient for verifying a code-signing identity, even automatically like LetsEncrypt does for TLS.
in order to have your code signed right now, you have to purchase a signing certificate. so we're already enforcing a "you have to buy this thing to have your code signed" rule. there's no reason that thing you have to purchase couldn't be a domain name instead - it's no more onerous than making the developer purchase a cert, but 99% would already have one.
When switching providers, I don't suppose you tried K Software? Mitchell Vincent has fantastic personal customer service. Been a while since I last used his services, but he's always been patient & helpful when I ran into issues getting verified:
https://www.ksoftware.net/code-signing-certificates/
That said, I've noticed a lot of big companies in the music industry stopped signing their software altogether and distribute it unsigned now. Doesn't seem to have hurt their sales - or maybe even improved it, there's less lag on Windows launching an unsigned app.
Woah, talk about burying the lede? This sentence makes it sound like their private key was compromised, in which case it makes total sense to revoke the cert. Unless I'm misunderstanding what they're trying to say here.
I doubt the CA would lie about the existence of such a file, although perhaps they are mistaken about the signature (it could be a case of a 570 MB file concatenated with a legitimately signed winrar executable - signatures don't always cover all parts of the file)
I don't think virustotal accepts files larger than 500 MB.
1. VT has an upload limit of 128 MB. (Maybe the private API allows more, not sure.)
2. VT allows sample download if you have a VT Intelligence account - so if this was a file shared with VT, the CA should be able to provide the file.
Would probably also put the CA out of business in no time if they did.
It’s very easy to see two steps ahead on this
by whom? the platform makers (apple/microsoft) or malicious third parties?
Whether or not we care for the contents of the agreements is a separate issue. Apple did not capriciously act against Epic - if they had then Epic wouldn’t have had an advertising campaign and lawsuit ready to go within hours.
The situation with WinRAR is completely different and it doesn’t help anything in trying to conflate the two; indeed it just muddies the waters :(
If one company took over all the physical land on the planet, and had everyone sign agreements to essentially pay taxes to them with every transaction, would we still argue that that’s not only legal, but morally justified?
They became the market leader (and I say this as an Android person who dislikes Apple and would never own one) because it's not a public market - they offer a "premium" experience, and part of that is the heavily curated app store. Opening up the platform would undermine the whole reason why it's popular to begin with. As long as you aren't using a jailbroken device (and there aren't any current 0-day attacks, which are rare) you don't have to worry about downloading random malware or side-loading something nasty.
Not to mention that it would prevent Apple from enforcing things like sign-in with apple ID, which again reduces user convenience and undermines the reason apple products are popular in the first place. People buy Apple devices because they "Just Work" and are willing to trade away control of the device to get that convenience - there's no real difference between an iPhone and a flagship Samsung phone (for example) in terms of hardware quality, it's all about slickness and ease of use.
>If one company took over all the physical land on the planet, and had everyone sign agreements to essentially pay taxes to them with every transaction, would we still argue that that’s not only legal, but morally justified?
Do you not believe there is a significant ongoing cost relating to the Apple store? Bandwidth, storage, CDN, power and HVAC for equipment, other building / data centre costs, IT staff for maintaining the servers and services, developers to develop the store and maintain Apple's side of the arms race between malicious devs trying to fool Apple's automated checking and Apple trying to detect and prevent malicious apps being uploaded, other miscellaneous overheads (accounting, auditors, etc.)... why should they be prevented from collecting taxes to cover the costs?
I'm sure it would be profitable for Apple to some degree, but not nearly as much as people seem to believe - IIRC something like two billion iPhones (not sure if that includes other iOS devices or just the phones) of various makes have been produced, and almost all of those will have checked in regularly to the store for updates and installing new stuff over the course of the devices lifetime - how much bandwidth do you think that would use? Apparently the (ballpark) storage on a device consumed by an install of fortnite on iOS is around 8GB, multiplied by 100 million downloads... That would not all be concurrent and earlier install would have been lighter, and how much of that comes through Apple vs. Epic's own CDN I do not know (e.g. if they can distribute game content themselves), but in any case I'm sure it is still a massive load on the store IX.
I hate to rant like this but the whole "ApPlE gReEdY" argument with no consideration of the costs involved is really irritating, and I've been seeing it everywhere since the dispute over Fortnite kicked off - I don't know the actual figures but I'm sure there are massive ongoing costs involved in running the Apple store. Putting a significant burden on that infrastructure and then complaining when you get kicked off for not contributing to it is an incredible display of gall on Epic's part.
1) Apple's popularity at least partially comes from their highly restricted platform. If you don't agree with the terms of use for that platform, or want to develop on a less restrictive platform, you are not forced to use it. It's not a public utility, and forcing Apple to open it would remove one of the fundamental aspects that made it successful to begin with.
2) It's fair for Apple to pass costs on to the third party developers who consume their resources, and unfair for Epic to try and subvert this - especially when their obligations were made clear in the terms of use for the platform.
Epic "only" have a 17 odd billion dollar valuation, so while they're not in the same ballpark as Apple they are by no means some helpless small business getting crushed by a giant corporate bully. As I see it, Epic are throwing a tantrum because they want all of the benefits of using Apple's platform and none of the drawbacks. Cutting off services for customers who refuse to pay is the norm in pretty much any other instance - why should this be different?
#1 I agree with the value proposition of Apple's App Store.
I disagree with your conclusion in two ways.
Treating these digital marketplaces, including App Store, the same as traditional physical marketplaces would remedy most of our current drama. I'm not saying we must nationalize these private platforms, thereby transmuting them to public open markets. I am saying that given their current economic importance, they must be normalized.
The job is as yet not done. As a long time enthusiastic Apple customer, I demand that App Store continues to improve. I want more curation, more safe guards, more fairness. Yes, for customers, App Store is currently best in class. And yet that's a pretty low bar.
re #2. The only opinion I have on the Apple vs Epic vs Fortnite slap fight is that any and all other content providers should also be able to fight it out with Apple on similar footing.
Even Amazon’s S3, which is arguably one of the more expensive places to store data (and which covers all of Amazon’s overhead plus a healthy profit) is $0.023 per GB. Even the cheapest paid app/IAP is $.99, which gives Apple $.33, and is likely 100-200MB. In the 8GB case, that’s still $0.184 and there are a lot of potential IAPs to “make up costs” and use 0 bandwidth.
When you run the actual math, it’s very hard to argue for “massive ongoing costs” and “significant burden”, especially when Epic has said that they would host and distribute the files entirely themselves if given the ability.
Well, that's basically the definition of a country, so...
Edit: countries tend to define what is legal.
...or that the certificate was no longer in compliance with their Certificate Practice Statement. It looks like their CPS gives them a great deal of leeway here. https://sectigo.com/uploads/files/Sectigo-CPS-v5.2.pdf#page=...
From the view of the certificate holder, the CA has one job: Keep their certificate valid. Everything else (including the trustworthiness of the CA, e.g. whether they issue false certificates) only matters insofar as it affects that job (if the CA were to screw up up badly enough to get removed from certificate stores, the certificate also becomes invalid, but other than that, the certificate holder doesn't really care how the CA acts).
By relying on a CA known to take such action (whether justified or unjustified), you're putting the continued usability of your software at risk, i.e. there is a strong reason to pick any other trusted CA.
https://sectigo.com/resource-library/comodo-ca-is-now-sectig...
It's got to be one of the most well known tools in the entire windows ecosystem.
What’s worse is that not all AV vendors on Virus Total have an easy way to submit a false positive report and of those that do, the majority believes getting a false positive report to be an opt-in into their marketing mailing lists.
I absolutely hate my about quarterly task of going from a name of an AV engine on Virus Total who suddenly decided that our binary which hasn’t changed on months must be infected to finding the actual submit-a-false-positive page to then writing the report and then unsubscribing from their mailing list I inevitably end up on
And VirusTotal bears a large responsibility for this too - not only do they not make it easy to find contacts for the various anti virus engines as you have pointed out (while disavowing themselves of any responsibility), they will highlight a "Generic" AI bullshit detection from some random company in the same way as verified malware.
VT has it as malicious with the new hash too [1] .
Antiy-AVL calls it Win32.Shelma. Only good definition that seems to match that detection is from Kaspersky [2] stating that the 64 bit version is detected as using metasploit [3] components.
[1] https://www.virustotal.com/gui/file/21dd688a5371f5b0d297a307...
[2] https://threats.kaspersky.com/en/threat/Trojan.Win64.Shelma/
[3] https://www.metasploit.com/
edited: formatting
Shiny new features require Secure Context so (other than on localhost) you can't do them with HTTP at all. That means things like Geolocation, WebAuthn, Service Workers, and essentially anything that's actually novel (couldn't just be polyfilled with Javascript). There are even old features getting deprecated in non-Secure Contexts because in hindsight we should have required Secure Context but it was hard to pull the trigger. For example EME (the DRM for some video content online) will probably require Secure Context.
Browsers are also adding back scary warnings for some more basic features like form submission when used without Secure Context.
And some domains (including entire TLDs) are locked down to forbid HTTP anyway. If you type in an HTTP URL in those domains it's rewritten as HTTPS and you can't undo that†
† Some browsers can override this as a corporate policy, so if your company really wants to be less secure it can disable the upgrades for some or all domains. But out of the box this is how the browser behaves.
Regardless, 7zip does not have as much of a need for a certificate because it is foss so you do not need to trust the creators, in comparison to winrar which isn't and you need to trust them.
Codesigning is a protection racket, and FOSS should not feel pressured to participate in it.
Do anyone pays attention to this? There is a lot of legitimate software you can't install without clicking through. 7-zip is just one of them.
https://www.digicert.com/blog/ms-smartscreen-application-rep....
Even if you sign your exe and build package, you have a 50% chance of being detected as a virus by some "heuristic" AV engine (looking at you, Norton and Kaspersky).
Basically, the heuristic is anything new = suspicious.
Unfortunately, I can't find any update/conclusion.
However, I did find https://sectigo.com/resource-library/the-what-when-and-why-o..., where Sectigo (the CA that presumably revoked the certificate, formerly also known as Comodo) mentions a previous incident, confirms that they didn't notify the certificate owner in that incident, and promises to "review" their practices. Given that RARLAB wrote "We had not received any notification, neither before nor after the revocation", I suspect Sectigo didn't improve.
Heck, WinZip still makes new releases so I'm sure people still use that too.
Genuine question: what are the better alternatives?
I think that they also support more archive formats and they even have their own open format 7z.
Based on their own claims, there are also faster and more efficient than Winrar.
I'm amazed at all the comments calling for 7zip as the one and only. winrar works just fine so does windows zip function. If you have an edge case, yeah then you need something that can handle it.
This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?
The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow.
There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.
But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason.
I'm not aware of any newer APIs that can natively accept long path names, btw,
The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths. So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't...
Incidentally, the other common application which can handle long paths is git for windows.
As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines.
BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP. But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up.
[0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming...
I used to use 7zip, but switched when I discovered that Peazip doesn't extract to a temporary directory when extracting (thus, saving extra I/O work). It directly extracts into the target directory.
Moving many (small) files can also be quite slow
I thought the creation of the files in the temp directory was an unavoidable artifact of how drag-and-drop worked in Windows. If peazip can get around this, I might check it out.
7-Zip covers the majority of other formats you're likely to encounter.
If I recall correctly WinRAR can make self extracting archives pretty easily. If you use that feature it might be easier/better to just continue using WinRAR.
I love the fact that small software companies like RARLAB can still exist.
WinZIP, too: https://www.winzip.com/win/en/lanall.html
For decompression only. 7zip can work with these too. In fact 7zip (unlike winrar) can even create some of them.
Granted, it's also famous for (supposedly) nobody ever paying for it, which doesn't exactly lend itself to staying in business.
They could at any point have changed the software to prevent it from functioning after the trial has expired - they're not going to be so naive to think people will all pay just because of a prompt that can be easily dismissed.
First of all, I very much doubt that the people who use winrar even notice the UI. They could switch to 7zip and feel right at home. People are used to UI changing drastically all the time, both from Windows itself, and from websites. Some of them complain about it, but even they adjust.
Second, I said nothing about "another compression algorithm". All the big compression software on Windows support each other's algorithms, but 7zip is free and winrar makes you pay for it. Also the people who use winrar don't care about compression algorithms in the first place, only that they get a file they can email and the other people can double-click to extract.
Third, the reality of the situation is that most people who use winrar are also the kind that use the trial version indefinitely. The more clued ones switch to pirated copies from piratebay et al. I'd rather people use 7zip than pirated copies, both for their safety and for RARLAB's benefit.
The reason these companies charge for things that are free is because they rely on users not knowing better, and the small fraction of users who do pay for it is sufficient to bankroll them. A 7zip user and a winrar user could be friends for life and the topic of "So what compression software do you use?" might never come up.
>If I recall correctly WinRAR can make self extracting archives pretty easily.
So can 7zip.
>I love the fact that small software companies like RARLAB can still exist.
You say this as if the alternatives are all big software companies. Last I checked, 7zip is still a one-person software.
Nope. 7-Zip feels very clunky. WinRAR is a lot smoother. People would notice that something feels "off", even if they couldn't tell you what specifically was wrong.
> You say this as if the alternatives are all big software companies. Last I checked, 7zip is still a one-person software.
Does that person make enough to live on?
https://sourceforge.net/p/sevenzip/discussion/45797/thread/9...
I think I shamed someone out of using 7z recently by pointing out that if they claim to be trying to attract a broad audience of hobbyist developers, using a compression library that doesn’t exist on OS X (with out without Xcode) is not a smart plan. In this particular case you had to download two tools to use their code, and that just tore it for me.
When I went back recently they had switched to .xz, which does exist.