Comment by weinzierl | Hacker News Reader

Comment by weinzierl | Hacker News Reader

Call me paranoid, but every time I install software on Windows [1] I do the following dance:

1. Search for the name of the software on Google [2].

2. Open link to software in separate tab.

3. Open Wikipedia link (usually on the same SERP) for software in separate tab.

4. Compare domain name from direct link with the domain name from the Wikipedia article.

5. Open another tab and type domain name manually.

6. Find download link manually on domain[3].

I do this since a family member got burned badly by a malicious OpenOffice install many years ago.

[1] Sometimes I do it on Mac too, because the App Store has it's own issues (e.g. upgrades are often cheaper if you buy software directly). On any other system I use the package manager. All of this makes the effort bearable because I only have to do it rarely.

[2] I'm usually on DuckDuckGo, but for this I always used Google. The reason is that I had hope that they'd remove malicious results quicker. It's manual work after all and Google has more resources. This whole thread makes me doubt though.

[3] I'd do this anyway because I usually don't want to install the version that is automatically suggested, but decide myself which specific version I want to install. Most of the time the reason is the language.

Disclaimer: I'm the author/maintainer for AppGet [0].

What you explained here is one of the main selling points (as in convincing, appget is completely free) for appget.

AppGet pretty much automates what you explained here and more.

We automatically download and validate SHA256 of downloads (We have a strict policy of only allowing releases from the official source)

All package info that is used to install applications are fully public in our GitHub repository [1] (think homebrew)

Also, for less tech-savvy users, they can install applications through our gallery e.g. https://appget.net/packages/i/chrome using appget as long as they have appget installed on the machine.

[0] https://appget.net

[1] https://github.com/appget/appget.packages/tree/master/manife...

Is there a readme on the website, github, or elsewhere? Do you have a plan to monetize AppGet?

you can read the documentation at https://docs.appget.net

As far as monetization, we do have plans for a paid offering, internally we are calling it "AppGet for Fleets" it'll be to manage/monitor app installation on a group of computers remotely using a hosted dashboard (SaaS offering).

AppGet as you see today and all of its stand-alone features will remain free and opensource.

I use Chocolatey right now. Are there any particular advantages that AppGet offers over Chocolatey?

There are a few :)

AppGet doesn't use custom scripts on install; everything is defined by data (YAML files). The client uses the data in the manifest and knows how to deal with different installers. This alone makes appget more secure; if you trust the client (it's opensource and managed by the core team) you don't blindly run a PowerShell script as admin on your machine.

Also, adding/updating packages is trivial since all you need to do is update/create a very simple YAML file. Another benefit is we can upgrade the client to better deal with let's say MSI installers, and none of the manifests need to be updated since all the logic is in the client, the manifest only needs to identify itself as MSI.

This also means you can install an app in different interactivity levels, Silent (everything happens in the background), Passive (you see the installer and progress, but you don't have to click next or do anything) or Interactive (appget downloads and validates the installer and just launches it for you, but you can run through the installer and customized it as you see fit)

Our packages are more up-to-date. We have a crawler that checks for updates on regular bases, we use GitHub api, and check vendor sites constantly (over 500K of check events per day). Trivial updates are automatically pushed to the repository, For non-trivial ones the bot automatically creates a pull-request on GitHub to be reviewed by a human. Most cases we pickup updated releases for apps within hours.

AppGet can list, upgrade and uninstall apps that aren't even installed using appget. We check windows installer database as the source of truth. You can download appget right now, run "appget outdated" and I guarantee it'll find outdated apps for you.

I'm sure there are more things, this question comes up a lot, so I'm gonna spend some time and add a page to the documentation just for this.

Chocolatey completely turned me off from Windows package managers. I'm sure you're familiar with all of the sore points that make it more hassle than it's worth.

But your description of AppGet has convinced me to try it out. Thank you!

Edit: There seems to be no obvious way to globally set the install location for apps. This is critical for my setup, I don't install apps in Program Files, because my Windows partition is lean and on an ssd that is shared with other VMs. Apps are installed in another drive location. Is there any way to do this currently?

Thanks for the feedback, right now there is no global way to set this. However, I just created a GitHub issue for it https://github.com/appget/appget/issues/14

In the meantime, what you can do as a workaround, is to use `-i` param when installing apps to launch the installer in interactive mode. That will let you run through the installer and customize everything including the install location. I know it's not ideal, but if you want to use appget to automatically download, validate the installers and check for outdated apps, it might be a reasonable work-around.

Still a good enough workaround to leverage the benefits of the trusted repository. Thanks for the tip! Definitely interested in seeing #14 get addressed :)

Thanks so much for the response, and I am sure it does get asked a lot. I will be sure to keep an eye on your project in the future!

> 5. Open another tab and type domain name manually.

I think this point is vulnerable to typosquatting and could actually reduces the overall security of your approach. I would say if the Wikipedia link matches the search engine link you are good to go.

My reasoning is that someone could change the Wikipedia link to a look-alike domain and that this could easily go unnoticed for some time. Even if the domains visually match they don't need to be identical (Unicode Confusables [1]), but the plain ASCII version that I can type on my keyboard is probably the right one.

[1] http://unicode.org/cldr/utility/confusables.jsp

I use ninite.com to achieve the same thing with less pain. The downside of my approach will only be revealed if ninite.com for some reason goes dark or to the dark side. I hope it doesn't happen and that if it does happen I hear about in time to transition to your approach!

I do a simplified version of it:

1. Search for the name of software on Google.

2. See if something looking like a site for the product shows up.

3a. If a product site shows up, I take a careful look around, and if it feels legit, I manually find the download link and use it.

3b. If a SourceForge link shows up, I proceed to the download. This is rare, but some program authors don't bother setting up their own sites, and I'm yet to see a malicious SF repo.

This is less secure than your procedure, but worked well enough so far.

I do this too. Perfectly normal.

Except people who are more tech-illiterate don't do it, and we're the minority here. It shouldn't be normal.

I have a deal with people who I love most. They are NOT allowed to install new software without my supervision. In return, they buy me coffee/treats for the help. It works! I presume this deal will continue to exist until binary signatures become a thing of importance for the end user.

Well... normal for the 1% of us tech savvy computer users.

This reminds me of a podcast I listened to last night where a physician explained how to get a flu shot: go to your place of work and do it yourself. Of course she was being sarcastic.

I would also add:

7. Scan installation package using VirusTotal (Ignore ClamAV and Chinese A/V results).

Reply on news.ycombinator.com