> We think that revoking certificates based on questionable data discredits the certification system.
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.
The other consideration is that verifying identity is pointless, because malware authors don't actually use their own identities, they just pull a code signing certificate from the 1% of their already-infected users who have one. Then they go out and infect a million more users with it and get 10,000 more code signing certificates.
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.
That doesn't rate limit wealthy attackers, it just locks regular individuals out of the system. Peter Thiel could still buy 10,000 malicious certificates at $500/ea, while I wouldn't even be able to buy one for a simple project.
To be fair, the former isn't really a problem; most malware authors are profit-motivated; they're trying to scam/phish/ransomware/etc people. If you increase their operating costs sufficiently, they'll go away. The ones who can afford to eat certificate costs mostly have nation-state connections they can use to get around identity verification anyway.
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.
>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.
> 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.
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.
This is why code-signing certificates must be two-factor (e.g. embedded on a PIN secured smartcard where the private-key is protected from extraction by anybody).
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.
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.
I understand the PIN is sent directly to the smartcard that performs the signing - not on the host PC - and it's required for each signing operation. So if malware did intercept the signature process and sign itself, I would notice that my originally intended software wasn't signed - that would hopefully be a hint to me that something was amiss and my computer was compromised.
There's another aspect of this situation that also discredits the system: that they can just go out and get a different cert from another vendor. How many such vendors are there? How long would it take for an actual bad actor to have all their certs discovered and revoked? If that time is long, then the certification process is of even more dubious value, since the bad guys would not be materially hindered by the certification requirement.
Take a look at the "Baseline Requirements for the Issuance and Management of Code Signing Certificates"[0] - specifically section 13.1.
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.
On some level I get it but aren't cash cards a thing? What actual level of identity and KYC do these cert companies do? How easy is it for someone without scruples to get another cert without revealing their identity? (Genuine questions: I do not personally know.)
Let's Encrypt's argument for why all the fancy features that CA's offered boiled down to "These are more complicated ways of proving that you own a domain". So by automating the verification of ownership of a domain you could essentially run a CA for pennies per certificate, and give them out for free.
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.
>I don't know if there is one thing that every app has like a website.
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.
A domain name costs less than a dollar. A DBA or real-life identity cost significantly more. In addition, if I'm getting my software over the internet (99.99% of the cases), I'm already verifying the domain name via the browser (via tls), so it's not adding any additional security. If the server was hacked, the attacker can mint himself a new certificate and you won't be able to tell.
microsoft.com or debian.org would cost a lot more than $1 and I would trust signed or unsigned software downloaded from either a lot more than from a random domain name. Code-signing definitely adds the benefit of offline key management; there is less risk of signing keys being stolen than TLS keys. But the valuation of trust is rooted in the domain; if Debian has to revoke all their keys for some reason I'll trust debian.org over any other source for re-establishing a root of trust unless a significant fraction of the Internet and mailing lists are crying foul, and even then I would probably wait for control of debian.org to be settled before trusting any Debian repositories.
I still think that demonstrated control of a domain is sufficient for verifying a code-signing identity, even automatically like LetsEncrypt does for TLS.
I agree that it would be nice to have a letsencrypt for code. The biggest hurdle I see is getting the the root trusted by OS vendors. While not impossible (the browser vendors did it), trust on these platforms may be a bigger issue since the code runs natively.
That’s less huge of a hurdle than it sounds. Root certs can be installed as part of an application installation or baked into a custom corporate OS image. Both of my employers have their certs installed in their corporate Windows images.
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.
That's true, but then you don't need something like let's encrypt. If you're doing this for an environment you already control you can have your own CA. Unless you are proposing a solution where each installer for these applications bundle the root cert so only one need be installed to trust all others. That's an interesting idea.
> I'm building a desktop app, and the process to even get a certificate is absurd...
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:
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.
> another explanation, i.e. that one reason for the revocation is some mysterious 570 MB executable file, which had been signed with our certificate but looked like a file used by hackers.
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.
You are misunderstanding. WinRAR's implication is that the CA is lying about the 570 MB file because they didn't mention it until WinRAR challenged them on the VirusTotal justification for revocation, and because they were unable to provide the file in question or any evidence that it exists.
Why not at least link to the virustotal listing for said file? Perhaps someone else has it from the hash?
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)
The WinRAR post doesn't say that the file was submitted to VirusTotal, only that the CA said it "looked like a file used by hackers". Either there was no VirusTotal record for it or there was and WinRAR omitted that fact because it weakened their argument.
Also this file (if it existed) was used to justify a business critical decision. Why wasn’t there a paper trail for this file. Why wasn’t this data archived?
I would have incremented the version number so the likes of Chocolatey would pick it up and replace the version installed with a revoked certificate as part of a regular update.
With both Windows and MacOS both putting scary warnings and hard to bypass blocking methods on improperly signed software this could eventually lead to developers being ransomed, “pay us big money or we will revoke your certificate”. This is not the only incident like this.
Epic violated the agreements they signed with Apple.
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 :(
I’d argue that it’s more similar than it seems, but with one caveat: Apple (rightfully) became the market leader, but is essentially running what should be a public market.
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?
It’s funny that when Android needs to prove its superiority during some arguments it’s the market leader, but when Apple needs to be flagged for a monopoly they’re the market leader.
> If one company took over all the physical land [in a prohibitively large area], and had everyone sign agreements to essentially pay taxes to them [...] that [that is] legal
Well, that's basically the definition of a country, so...
>Apple (rightfully) became the market leader, but is essentially running what should be a public market.
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.
> 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?
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.
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.
Where and when did Microsoft or Apple yank someone's developer cert for the sole reason of criticism? An accusation that serious needs to be substantiated.
That's fair. If you have specialized needs, you might be in trouble. Users clearly prefer to exclude people with specialized needs so I now understand why you are worried.
Not a lawyer but I suspect there's a viable tortious interference claim. Revocation is effectively telling your customers that your product is unsafe, if done without cause it could be actionable.
The main clauses either require a reasonable belief, which is a factual question that could easily go against the CA, or says they need to be "identified" as publishers of malicious software, without specifying how. An antivirus site that has many false positives likely wouldn't qualify.
This is the most important information in this. Other people who are looking for code signing certificates should use this information to choose their CA.
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.
I know the authorities need to err on the side of caution, but it's quite astonishing to me that someone at the authority didn't just say 'It's WinRAR...' and let it slide.
It's got to be one of the most well known tools in the entire windows ecosystem.
If it were just the file not being clean on Virustotal I would fully agree. Heuristic detection will result in false positives. However, if they had an actual example of malware signed by that key that would indicate a compromise and that would justify pulling it. The absence of the offending file is suspicious, though.
If they had an example, they would've never deleted it though. I mean, that part is so unprofessional, it's rude to believe are that incompetent, the polite explanation is that they lied about it.
Yep, it would certainly justify pulling it, but quite bizarre that they're then refusing to issue another certification - I'm sure the WinRAR team would be able to prove they're the genuine developers.
This CA sounds kinda incompetent. Even if you ignore the fact who winrar is, just the nature of the tool itself makes its silly to use virustotal as the gatekeeper.
Build servers being compromised and used to inject malware into trusted, signed binaries is a thing that happens. Being one of the most well known tools in the entire Windows ecosystem makes WinRAR a particularly juicy target for trying to pull that off.
The winrar trial has ads in it that try to load activex controls using embedded IE webview; an obvious security concern. I reported it and they suggested I enable activex.
At my previous job we released updates to our Windows desktop application about 3-4 times per year. We had about 20'000 customers (but many of them not installing updates). We checked final build of our product on Virus Total before release and e-mail the various anti virus companies about the false positives. Thankfully, I wasn't the guy doing this work.
Unfortunately that doesn’t really help. We update an application about once a year but we get false positive alerts even months after AV programs have previously not complained about a binary.
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
How is what these virus companies are doing not defamation? Are there any legal options you have when this happens to you?
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.
Weird. Though there would be value in working with the vendors backing VT to get this fixed as this is just one of the issues with a false positive. Another is that users who use these products are probably alerted or otherwise prevented from using WinRAR too.
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.
It is particularly ironic that so many people in this thread are recommending 7-zip in response to a cert problem with WinRAR when 7-zip has no code signing at all and presents the scary yellow "unknown software" screen when you try to install it.
I didn't even realize that the "scary" yellow prompt was related to code signing. For me it was just what happens when you run an executable from the internet.
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.
Just code signing your application isn't enough, it needs to get enough reputation from enough Windows spyware bots reporting they installed your program:
It's a bit like the way that plaintext HTTP is way easier to deal with than HTTPS, and the way browsers treat a self-signed cert as worse than no cert. Which... does lead to some odd outcomes, yes.
This (the "positive indication" problem in HTTPS) is gradually being fixed.
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.
The fact that it is FOSS makes it _easier_ for someone to compile it with a backdoor or trojan. I would say the need for a certificate is _higher_ there. You don’t need to trust the developers, you need to be able to trust the people who have built the executable.
Well, viruses existed for ages, so I do not think that it really makes it easier. The reason that you do not need a signed executable as much is that people can just compile one themselves.
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.
I wish Winrar licensing worked differently. If I could buy a license and get a permanent key to save to my email or a text file I'd gladly spend the $20, but buying a separate license for every computer is just too much mental labor to keep up with when it works fine for free.
Or maybe their customers just like the product, as in the GUI and feature and don’t care that another compression algorithm can shave off a few extra megabytes.
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.
> Or maybe their customers just like the product, as in the GUI and feature and don’t care that another compression algorithm can shave off a few extra megabytes.
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.
> 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.
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.
I wonder how profitable they are. In Poland WinRAR was big at the time (still sort of is, but 7-zip taken over a lot of users), but buying license was actually point of jokes and memes. Everybody just used shareware trial and closed that nag window every time.
That's true, but considering how widespread the software is, it's likely that they only need a tiny percentage of the overall user-base to pay to remain a sustainable 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.
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.
In response to WayToDoor, some archives contain thousands of files, and it's essentially doubling the number of filesystem operations by putting them in a temp directory and then moving. If the temp directory is on a different drive from the destination, then it's recopying all the data.
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.
Avoiding a temp directories is usually a good thing, unless the temp directory allows you to avoid operations on removable drives. I've noticed on windows with drives marked as "removable" it's almost always faster to copy an archive to the harddrive (non-removable drive) extract it and copy the contents back. I'm assuming this is because of the different or lack of caching available for removable drives. Random read/write is typically a lot slower that sequential read/write so an ideal solution would take into account the relative performance of different drives before with making or not making a temp folder.
I run into the issue sometimes cross-volume, where the file gets extracted into a temporary directory then has to be copied to the actual destination, into e.g. a network volume or second hard disk.
Back when I used Winzip/7zip, they didn't move files: they copied files. When you're working with files measured in gigabytes, the speedup is quite noticeable.
depends on the move operation.
1 file you would not notice it. Thousands it would add up. Across 2 physical drives you may also notice it if the file is big enough.
For zip files in particular, you can just right click and 'Extract all' in modern versions of Windows. I believe you can also double-click to open them like folders in Explorer.
7-Zip covers the majority of other formats you're likely to encounter.
It can extract files to paths of more than 260 characters, without any extra tools or registry hacks, on any version of windows (even xp).
Winrar cannot.
As a bonus, 7zip can also delete folders with file paths that are over 260 characters from its file manager ui. It has been one of the only programs to be able to do so for many years.
To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem.
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.
You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either.
Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think).
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.
Amount of times this has been an issue with using Winrar for 15+ years : zero.
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.
FWIW I agree with you, personally I also prefer Winrar, and have used it for many years with zero issues. I like its ui better than 7zip's. But the 260 chars is the one edge case that happened to be important to me and so I decided to switch.
I have found that some multipart rar files fail to extract properly with 7zip. Most are fine though, but I normally have the unrar-nonfree package installed for the few that don't work.
Had a similar issue with some rar files but the latest v20.02 seems to have solved it and everything work fine so far, also if you want try to report this issue on their forum.
That's the single remaining killer feature of RAR for me. I think the last time I actually used it was years ago when pulling a backup off of a degraded DVD-R, but it still provides a bit of peace of mind for long-term storage.
It's the same thing as comparing Dropbox to an FTP server and Rsync. You can use it, it can be more powerful, but the unified experience is more convenient.
Somehow archival tools have become political. 7zip seems to be the new one people use even though that means their users now have to download and understand two packages instead of one. It’s off-putting, especially when downloading your tool was already an act of yak shaving. As awesome as we want to think our tools are, the people who use them may be preoccupied with other problems instead. Friction will not convert them.
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.
zip is hardly the only compression algorithm, or the best one for all conceivable use cases, and tools like Winrar (and 7zip, for that matter) offer additional features that the OS tools do not.
I do use 7-zip myself, but WinRAR has still a more feature rich user interface out of the box than 7-zip and while 7-zip has better compression in general, compression isn't everything when they're this close to each other, like a few percents different ratio.
Ebooks available on IRC are often compressed as RAR files. More often lately Epub books are not being compressed since Epub files are already compressed, and compressing them again as RAR files doesn't really gain you anything.
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.