100 comments

[ 3.6 ms ] story [ 187 ms ] thread
Can’t live without it on Windows!
I'm using this on Linux servers because it give me better compression and utilize all processor threads.
Although potentially missing the point of the original submission: https://github.com/M2Team/NanaZip

imo better integration with Win 10/11 context menus and more compression codecs

Thanks for the recommendation
Thanks for the recommendation! NanaZip solves a problem that I have had with Explorer integration in 7zip. 7zip's right click menu does not appear for files that are synced on OneDrive but not downloaded to the local machine. NanaZip handles this correctly.
I guess the main purpose of the submission has been lost, as HN resolved the redirect ahead of time. https://seven.zip redirects to 7-zip.org .
Thank you for posting this - I couldn't figure out the intent of the initial post without this comment.
I guess a more useful title could be: "seven.zip redirects to 7-zip.org".
I believe the point of the title was to make it feel like it's a link to a zip file and not a website.
No, I actually just hoped there would be 7.zip that leads to 7-zip.org. But found out it was seven.zip.

I hope apps will not make links out of .zip TLD.

I assume this post was to show a new URL - seven.zip - with the new gTLD .zip being popular news the past week?

Sadly it seems the address was 'corrected' and instead was posted as 7-zip.org

If you go to https://seven.zip it does indeed redirect to 7-zip.org :)

Did HN resolve the redirect? The domain https://seven.zip redirects here.

I was wondering why this submission with this name, when the page title is 7-zip and the download is a .exe and not called seven.zip or so, but then remembered the recently (stupidly) approved TLD that is .zip

Edit: well https://i.snipboard.io/uAo7BG.jpg

Yes, about the new TLD. Seems like HN resolved domain redirect and changed link to 7-zip.org

I was actually hoping for 7.zip :)

I like 7zip except for one thing, you cannot redirect it to stdout, or I could not find a way of doing that.

7z -something < file.7z | whatever > out.file

Personally, I would use 'xz -9' if I wanted high compression, it works better with UNIX type systems Systems.

FWIW, I decided to compare the compress size between xz(1) and a very large 7z file, using 'xz -9'.

Sizes:

* uncompress: 36,495,045,244

* gz: 18,729,830,001

* xz: 16,739,567,484

* 7z: 16,257,755,606

7z ended up being about 480 meg smaller, in a way that was a bit unexpected. I was expecting xz to be slightly smaller.

Also, this process took about 15 hours.

These redirects are cute, but how can we be sure that the domain is owned by the same people as 7-zip.org? I can imagine an attack scenario where someone with malicious intent registers seven.zip, initially sets it up to redirect 7-zip.org. People start using this new URL and then after a while seven.zip starts to host a mirror of 7-zip.org with a malicious installer.

Not trying to accuse anybody, just wondering.

The real answer is that trust isn't needed, because you just shouldn't use it.

You know that 7-zip.org is the official site. You see that's where you end up after the redirect. Just bookmark and use that. No reason to add more steps.

The real answer is: trust is not a problem that can ever be fully mitigated by smart technology and that's why we depend on things like the wonderful package maintainers of debian and other projects to do due diligence for the rest of us!
Even typing in a domain you know can be fraught. There are still plenty of popular domains with common typos registered by shady people. Most of them I encounter tend to be spam sites rather than maliciously impersonating the site they are trying to steal traffic from but that's not a far leap. See https://news.ycombinator.co
until a Node coder withdraws a tiny-but-widely-referenced package.
That might be the real answer, but not very satisfactory, as it suggests that this domain just shouldn't exist.

At least 7-zip.org could have a list of domains that they own and control if they wish people to use these alternate domains.

> if they wish people to use these alternate domains

I would have assumed the main reason to register alternate domains like this would not be so people can use them, but rather to prevent others registering them and abusing them.

Maybe, then it serves that purpose (if it's indeed their domain). But why redirect then or even point them to an HTTP server?

Anyway, I would never choose to fight this battle, feels rather futile. It doesn't help that they have a dash in the name, so they have to hunt down names with 7-zip and 7zip as well.

That's the only reason that I have done it with my domains. I don't use a redirect, though, I just have the DNS records resolve all the alternate domains to the same IP address.
> You know that 7-zip.org is the official site.

How would I know that, tho? What if 7-zip.com is the official, and 7-zip.com is a similar site with a malware?

The squatters just need to start saying that "seven.zip" is the new home page and 7-zip.org is deprecated instead of redirecting.

It only takes some SEO to make it look plausible for many users who trust Google and see "seven.zip" as the first search result.

then you address it by reporting/complaining. It's already perfectly possible to do that, the only change here is a name. I'm sure there's also phishing detection (that will certainly improve with ML) that can help too.

either way, what's the solution to prevention? disallow the entire TLD and every possible TLD that could lead to phishing? there are already plenty of issues with .com being used for phishing. have a regulatory body do ID verification of every registrant and if it sounds like a domain that could possibly be misused then ... what?

Said malware would also have to be code signed with the 7-zip authors' code signing certificate. However, if you're downloading it for the first time, you wouldn't know what that correct value is.
Just wanted to point out that trust is already embedded in your scenario: where you say "you know", that really means that you trust, based on experience. The experience that gives rise to that knowledge is the same sort of thing that gives rise to the attack vector being suggested here.
Except the way most people end up with malware is searching for software and downloading the first result they can find.
The real answer is that .zip should never have been allowed as a TLD.
Selective/targeted redirection is possible based on geography,client.etc....
whois isn’t much use any more, but registrar doesn’t match:

  $ whois 7-zip.org
  …
  Registrar: GoDaddy.com, LLC
  …

  $ whois seven.zip
  …
  Registrar: Google LLC.
  …
Name servers don’t match:

  $ dig +short 7-zip.org NS
  ns01.domaincontrol.com.
  ns02.domaincontrol.com.

  $ dig +short seven.zip NS
  ns-cloud-c1.googledomains.com.
  ns-cloud-c2.googledomains.com.
  ns-cloud-c3.googledomains.com.
  ns-cloud-c4.googledomains.com.
(Aside: I believe these queries are strictly the wrong thing, asking seven.zip what its nameservers are, but you actually need to ask the zip. nameservers what seven.zip’s nameservers are. The two will normally match, but don’t actually have to, and in my crazy hacker dreams (you know, the ones where five dollar wrenches don’t exist) I can imagine the difference being used sneakily. But I’m not sure if there’s any good way of asking for the actual nameservers with dig, which is basically “`dig +short zip. NS`, then `dig +short @one-of-those-zip-nameserver-addresses seven.zip. NS`”, and yes, you’d need to follow more steps if you were dealing with a deeper domain name. Whois records are actually more convenient in general!)

And servers don’t match:

  $ dig +short 7-zip.org
  49.12.202.237
  $ dig +short -x 49.12.202.237
  static.237.202.12.49.clients.your-server.de.

  $ dig +short seven.zip
  216.239.36.21
  216.239.34.21
  216.239.32.21
  216.239.38.21
  $ dig +short -x 216.239.36.21
  any-in-2415.1e100.net.
These checks give no reason to suspect it’s legitimate.
That doesn't mean much though. Its hardly uncommon to just use the rigistrar's servers for a redirect for smaller project.
Step 1. Buy domain X' similar to X

Step 2. Redirect to X

Step 3. Gain popularity quickly and appear as a legitimate alias of X

Step 4. Take control of X

Step 5. ...

Step 6. Profit

The real way is to gpg-sign all of your distributed binaries, and tell your users to be careful where they get the corresponding public key.

This is both much-needed and incredibly inconvenient in the world of windows binary distribution.

I've always wondered what the point of this is. Why not just skip the signature and tell users to be careful where they get the binary? If I can't trust that the binary made it to me untampered, why should I believe the pubkey is any more legitimate?
Because the website itself or the primary domain server could potentially be hacked. More likely, your DNS service (or a maliciously edited /etc/hosts) could give you a dishonest resolution, sending you to the fraudulent address.

A public key does not exist in a vacuum. Ideally, it is part of a larger "web of trust", having been signed by others in that web. Unfortunately, websites like 7-zip.org do: they are socially isolated, which is where this situation of mistrust originated. Package managers (like Debian's apt or Archlinux' pacman) are at the advantage here, because the social coordination of a software repository sets the perfect circumstances for a web of trust; and the package manager itself automatically checks gpg signatures after downloading each package.

I think that's part of the problem, if you don't have that package manager to bootstrap your signature key ring, DNS is your next best bootstrap. It is, of course, a terrible bootstrap for trust, but it is one so many users on Windows have been relying on for such a long time.

For power users on any modern Windows 10/Windows 11 there is at least WinGet now. Its manifests repo is becoming a very interesting (open) source of truth for common Windows applications. Admittedly, it in most cases doesn't seem to be checking specific code signatures in most cases either, but at least includes SHA checksums.

For instance, 7zip's manifests: https://github.com/microsoft/winget-pkgs/tree/master/manifes...

It's too bad there's still not a great option for "average user that doesn't know/trust how to use a CLI", given how sadly polluted the Microsoft Store can be for many common, especially Open Source, applications. For direct instance, because winget kindly includes Microsoft Store results when searching, there is a "7zip 22" in the Microsoft Store that costs some amount of money (winget details say "PaidUnknownPrice" for the pricing information; I'm on a corporate machine right now with the actual Store access locked so can't search in the actual Store right now) and the Publisher is listed as RepackagerExpress.com. (That website currently doesn't go anywhere, giving it a spot check.)

Having seen this, I may boot up my personal machine and try to report this specific Store listing for violating the Store's Open Source policies, though I'm unsure if such whackamole is all that useful. (Seems like it might be a useful winget feature request for it to provide Store Report URLs.)

Microsoft Store is precisely what I expected it to be: what likely started as an effort by some in the company to reproduce the utility of a package manager, but in the end sabotaged by the perverse incentives of capitalism.

The Cathedral cannot emulate a Bazaar.

I think the point was the binaries would be distributed around different mirrors that might not be under the control of the author - so long as you got the key from the author the actual binary (which is a much larger filesize than the key) could have less secured mirrors.
This is where the TOFU model comes in, you implicitly trust the key on first use.

Finding a legitimate download one time is better than having to find it every time.

Bootstrapping keys is a difficult thing for sure, but TOFU is still better than nothing at all and seems to work pretty well in practice.

Check out MarkMonitor. There's a bunch of companies that worry about someone registering lookalike domains, or trademarked terms on alternate TLDs. This feels like a variant of that larger problem.

Without a statement on the official 7-zip site, I'd assume it's unofficial and untrustworthy.

https://en.m.wikipedia.org/wiki/MarkMonitor

It's a fair point, although that concept of trust happens with every domain.. including those that use another TLD for their content delivery network (example.com with images served from example.net), or SaaS app (example.blog with login.example.app).

In this particular case though, it's a 301/Permanent redirect[0], meaning it should be remembered forever. This includes the domain not being listed by search engines[1] (the target URL is used) and once you've visited it on your system it will remember the redirect indefinitely.

The point being, you don't need to trust who set it up, it's very hard to undo. If someone wanted to do this nefariously or reserve the right to use the domain in a different way in the future, they would want to use a temporary redirect.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 [1]: https://developers.google.com/search/docs/crawling-indexing/...

That's cool, but I feel like .zip might get caught by spam protection so not the best choice for sending in discord/email/chat etc

Speaking of domain names, what is the best option for the cheapest possible domain tld (including renewal), maybe something you can even get for 10 years and save a ton? Also would be nice if it had free whois? Extension doesn't matter as this would be for personal use. Is it still xyz or ovh?

.tk and .ml. It doesn't get cheaper than free and .ml is a great typo squatting TLD for .nl which nobody seems to realise yet so a lot of domains are still available. Educational purposes only!!
Unfortunately those also don't have a great reputation either.
A while back I noticed that .biz specifically has its own checkbox in the o365 spam controls. And sure enough I don't think I've ever done legitimate business on a .biz. I wonder what the heck happened to it.
Sending a .biz link in an SMS will be blocked by Google, and the sender won't be informed the message was not sent. Cheap domains are cheap for spammers too.
The only .biz I've ever interacted with is Minimus.biz, and it looks like they've barely touched their site since 2006. Just the way I like it, honestly.

Other than that, yeah, it's a cesspool.

Thanks for the suggestion, but I feel like the free domains are unreliable and have weird conditions. I also I think it's been said before some of the sites offering them are suspect: https://news.ycombinator.com/item?id=27951785

I was just thinking for personal projects & game servers, would be nice to have a bunch of cheap domains one could use.

I believe .tk and .ml are currently closed for registration after financial concerns and lawsuits about malicious domains. I'm working on a project that offers free subdomains under the condition that they are routed to private IP ranges. I believe this will reduce malicious use while still helping people use Let's Encrypt and other domain verified certificates.

It's still a rough MVP but it's online and working: https://www.getlocalcert.net/

The difference between a $9 and a $10 domain on a 10 year run is $10.
True but I was thinking more like a $1-3 domain for servers and what not
Well, $70 is a whole another deal, thats like a good time in a bar.. for 1 time.

Formatting prob sucks, on mobilr, sorry:

  cheapestdomainame.xyz$1.99
  MULTI-YEAR SALE
  cheapestdomainame.lol$1.99
  MULTI-YEAR SALE
  cheapestdomainame.org$8.99
  cheapestdomainame.me
  The connection to the central registry is busy. Please try again later
  cheapestdomainame.pro$3.85
  cheapestdomainame.co$3.49
  cheapestdomainame.gay$2.99
  cheapestdomainame.one$14.99
  cheapestdomainame.sucks$249.99
Last year, .stream was only $30 or $40 for a 10-year registration on Pork Bun. I have no idea if it's still an active price. They also sent me an e-mail about deeply-discounted domains, but I've hoarded enough domains I don't use and haven't looked at it. No clue if the prices are 1st year only or if you can buy a 10-year registration for the cheap price. Registars have a habit of giving a 95% off 1st year pricing and then charging $100 for renewal.

I've also heard .in is a good place for 10-year registrations (at another registrar I don't remember). However, .in domains do not have WHOIS privacy.

This reminded me to check, I had an old outdated version installed!
Is there an easy way to block/blacklist certain TLDs on Windows, or at least in Firefox or Chrome? Ideally without requiring additional tools.
People are hyperventilating about the "danger".

.sh also exists and the world didn't burn.

https://get.sh

".sh" is not a file extension that Joe User sees much of, to be more vulnerable to oopsies.
.sh probably shouldn't exist either. But I think .zip is a much more common file extension than .sh among the general populace.
.sh legitimately exists as a TLD because it's a ccTLD. ccTLDs are based on ISO country codes. In contrast, .zip only exists as a TLD because of ICANN money grubbing.
I'm still annoyed that ICANN approved .org without sparing a thought for the poor users of emacs org-mode which had been released -18 years earlier!
I propose that perhaps the problem is not top level domains but rather a certain operating system family's tendency to conflate file name extensions with file types, despite its default setting being "hide file extensions for known file types".
The world won't burn, but .sh and .zip are different.

If I send an email to my (less technically minded) family I may attach photos.zip. If I mention photos.zip in the body then the mail client may now convert it to a link. If http[://]photos.zip is a malware site, my family may download malware. I may inadvertently link to a malware site by talking about a zip file.

I could also send an email with "install.sh" as an attachment, and mention it in the body. http[://]install.sh could be a malware site too.

The differences. Non-technical people send, receive, and talk about zip files much more often.

.sh was also registered with a clear reason, it's a ccTLD, it's for a country. .zip is just a vanity gTLD. If Zipland was a country, I'd support .zip or ideally .zp. Without a clear purpose and with clear malicious uses, people are just going to block the TLD. Lots of IT folks talking about implementing it on Reddit.

Mail clients will quickly be updated to not convert photos.zip to a link.

Even if not, you have the regular browser protections against downloading malware which are always active (deny-lists, reputation, scanning, ...).

> Without a clear purpose

The clear purpose is freedom of expression. Why should TLDs be limited to country codes? Allowing generic TLDs also relieves pressure on .com and brings down domain costs, since now you can have an interesting.space or cool.site

> Why should TLDs be limited to country codes?

Google also registered .dad, .prof, .phd, .esq, .foo, .mov, and, .nexus. I've seen similar complaints about .mov, but there's no opposition to the others or gTLDs in general.

https://www.blog.google/products/registry/8-new-top-level-do...

I support freedom of expression through TLDs but there's a meaningful pre-existing use of .zip. It's not clear to me that the value of the TLD outweighs the phishing risk, the malware risk, the cost of software developers preventing x.zip from rendering as a link, etc. It's possible the TLD ends up on a block lists and eventually gets discontinued.

This orthogonally reminds me of the time when there was a massive kerfuffle when Google registered .dev and then included the entire gTLD in Chrome manifests as HSTS [HTTP-Strict-Transport-Security] required (HTTPS only) and that silently broke a lot of company's LANs and developer environments. (To be fair, don't use gTLDs that don't exist in your LANs, that was always a broken thing to do, Google just made it more obvious in that case.)

Google has made some interesting choices in the sorts of gTLDs it has registered since it has had the capability to do so.

> the phishing risk, the malware risk

.app is an extension used on MacOS for app installers. Yet the .app TLD didn't seem to materialize phishing/malware risk since it's 2018 introduction.

The exact same arguments were made back then:

https://news.ycombinator.com/item?id=16974572

https://cash.app/

The best archiving software on windows. Missing it on Mac.
What do you miss about it on Mac? Have you tried Keka?

https://www.keka.io/en/

For example, RAR support is not listed.
Since RAR decompression is listed, I'll assume you mean compression:

https://github.com/aonez/Keka/wiki/Rar-compression

Sounds like it is a licensing issue more than anything? People still compress to RAR?

Yep - I think it's mostly people who go by word of mouth and don't know about the leading free-without-cracks alternative, but RAR does still have some genuine merits like [native] optional redundancy!
Yes, I mean compression.

From the home page (https://www.keka.io/en/):

    Keka can create files in these formats:
    7Z ZIP TAR GZIP BZIP2 XZ LZIP DMG ISO BROTLI ZSTD LRZIP AAR WIM 
    
    And extract all of these formats:
    7Z ZIP ZIPX RAR TAR GZIP BZIP2 XZ LZIP DMG ISO BROTLI ZSTD LRZIP LZMA EXE CAB WIM MSI PAX JAR WAR IPA XIP APK APPX XPI WPRESS IS3 CPGZ CPIO CPT SPK
Somehow using default zip functionality creates files that are corrupt according other software.
I think it's not secure to have a domain extension like .zip. Imagine if people were to search for, for example, "install.zip," and there is a domain with that name and extension automatically assigned to it. It could potentially lead users to automatically download a malicious version of the "install.zip".