Sweetalert: Project might be malicious

Created on 15 Oct 2017 · 4Comments · Source: t4t5/sweetalert

Following from #733 which appears to be going off topic. This web project appears to engage in bad practise, forcing users to install software to their local environment to use it (npm), otherwise forcing them to use compiled and obfuscated code which cannot be verified.

I request that you include a simple method to obtain unminified source files to prove they are not malicious before use.

Source

daftspunk

👍9 ❤1

Most helpful comment

There is also SweetAlert2, which does have an un-minified version available. That could save some troubles. Works great.
https://github.com/limonte/sweetalert2/releases

ndcisiv on 4 Dec 2017

👍3

All 4 comments

Perhaps you can use subresource integrity for your particular use case? Support is not terrible.

infostreams on 23 Oct 2017

This is also a show-stopper issue for me. I package up my js and css into several bundles. Right now, there is no uniminified js code that I can pass to my gulp script. And there is NO way I am going to just blindly dump obfuscated JavaScript into my product's code.

If there is unminified code that can be reviewed, I can use this new version.

gtmadev on 11 Nov 2017

👍1

There is also SweetAlert2, which does have an un-minified version available. That could save some troubles. Works great.
https://github.com/limonte/sweetalert2/releases

ndcisiv on 4 Dec 2017

👍3

@daftspunk Thanks for separating this issue from the others in #733

I think this issue may be invalid...

I need unminified source files so I can prove they are not malicious.

This web project appears to engage in bad practise, forcing users to install software to their local environment to use it (npm), otherwise forcing them to use compiled and obfuscated code which cannot be verified.

We should create a new issue or PR "Provide unobfuscated build in package distribution". If that is rejected for no good reason, then I might be suspicious that the author is doing something malicious.

If it's accepted, then you can access the dist files, of any version, minified or unminified, via unpkg.com

https://unpkg.com/[email protected]/dist/sweetalert.min.js
https://unpkg.com/[email protected]/dist/sweetalert.js (COMING, but with a future version of sweetalert of course)

Keeping build/dist files in source-control is really going against widespread convention and causes pain with Git tooling. Check out the setup of the React project for instance. It is extremely standard, in that dist files are included in the package distribution on npm (check the umd folder) and not included in the source-code repository on Github.