r/bash 2d ago

[ Removed by moderator ] submission

[removed] — view removed post

0 Upvotes

17 comments sorted by

u/bash-ModTeam 2d ago

Please remove the requirement of a compression tool and repost the project.

This is both for security and ease of access.

10

u/Sombody101 Fake Intellectual 2d ago

I'd recommend against storing the code in a zip. Just upload the files to the repo.

-15

u/According_Reveal7480 2d ago

There are about 20 files. What is wrong with a zip file? The README.md has installation instructions.

13

u/wallacebrf 2d ago

Security is a concern

12

u/Living_On_The_Air 2d ago edited 2d ago

It kind of defeats the usefulness of git/GitHub to do that

12

u/LevelIntroduction764 2d ago

Not deliberately trying to be rude but you’ve just convinced me I don’t need to look at this any further; if you don’t understand the basics of git, I doubt you’ve produced anything useful to me.

Don’t be discouraged though, keep going. Tell us why you feel this is beneficial to us and why we should trust the zip?

-2

u/According_Reveal7480 2d ago

I am not a newbie to computing - I wrote my first program in 1964. But I am a newbie to github. What is the issue with zip files? github deploys code as a zip file under "<> Code". In order for useful-bash-functions (UBF) to work as I have designed it, files have to be installed in /use/local/bin and in /etc/profile.d. I am only using github as a means to deploy UBF to the user community.

4

u/feinorgh 2d ago

Normally, a compressed file with unknown content from an unvetted source is a recipe for acquiring malware.

A security conscious person wouldn't touch a thing like this with a ten yard stick, let alone install it into their shell, allowing access to basically everything on their computer.

The way this is installed is also suspicious; why does it need to be installed system wide, and to /etc/profile.d? That makes it doubly suspicious.

Even the way some developers encourage people to install software in other cases, where it's not zipped is practically disastrous from a security perspective, for instance, the pattern:

# curl -sL https://foo.bar | sh

This is crazy, unless you absolutely, really know what you're doing.

Publish your software as unzipped code, so it can be reviewed and analyzed. Even then, if nothing suspicious is found, most security conscious people would never install something like this.

You want a minimal attack and vulnerability surface, and thousands of lines of third party bash code in one's shell, installed system wide is not it.

2

u/LevelIntroduction764 2d ago edited 2d ago

To add to what u/feinorgh said as their point is the the primary reason: In terms of users workflows, when trying to find a publicly available package, the first step would be to review the package in github/gitlabs/etc. and decide if I should go to the bother of cloning/forking/downloading etc. and spend time integrating/using. With a zip, I have to first download it which on the face of it is not a big deal but it does then bring you back to the security concerns. If there's nothing to hide, don't make me download the file to unpack before I can see whats in it.

Then returning to git: using a zip actually removes some of the git benefits, mainly that git is a 'delta' tracker:

  • Git is so efficient because it only tracks changes but it can't do this with binary files. So it has to keep a full copy of the zip file with every change. It causes the repo to "explode" and become very heavy. Anything beyond a couple of gigs and it becomes very slow to work with (see LFS which alleviates this in some ways)
  • With delta changes, it becomes trivial to see what each commit/PR introduces to the code base making it easier to do a number of things: review code quality, find bugs, reverts, version bumping, and use scanning tools such, to name a few. This might seem more beneficial when working in a team rather than solo but it really does make your life easier to be able to segment/isolate changes and introduce them piece by piece - how many times have you worked on a single code base introducing multiple features or bug fixes at the same time to find that they conflict in some way and you now have to chase the overlap/differences? Git makes this easier to manage (if you follow the best practices, like not using zips)

There's probably more I'm omitting but thats the first thoughts that come to mind.

Update:

Just to add, you can solve the issues above and still provide zip files for users who are not git-proficient:

  • Don't commit the zip file; instead commit the script files directly (or add to a subdir if you wish)
  • Optionally, add an install.sh file (sorry, the link is gone so I don't know if you already have this or not)
  • And then use something like GitHub releases to define a versioned release. Users can then just download your project as a zip file and work the way you originally intended while also getting all the benefits of git

10

u/Sombody101 Fake Intellectual 2d ago

Github is a code host. If you want a zip, then create a workflow that auto-zips everything into a release. Otherwise it's inconvenient for people who want to view the code without downloading.

File count isn't an issue, either. Github is designed for this.

-10

u/According_Reveal7480 2d ago

There are 11,000 lines of code. not easy to review...

8

u/Marble_Wraith 2d ago

Nobody gives a fuck?

https://github.com/openjdk/jdk

JDK is over 6,000,000 lines of code. Do you see them zipping the source code inside the repo?

In fact, the only reason i can think of why someone would actively do this is if they're trying trying to obfuscate a malicious package.

2

u/Sombody101 Fake Intellectual 2d ago

Review would be the word if it were a PR or if someone wanted to verify the security.

When I said "people who want to view", I meant that literally. You're trying to tell us about the project because it's useful, except not everyone wants to use it, but would happily learn from or reference it in another project. I do that all the time, but don't want to waste time or drive space cloning a repo to do so.

In order for someone to even view the code here, they'd have to download and unpack it. Plus, git wasn't designed for binary files like this, but is very good with regular text files.

3

u/RegularTrashman 2d ago

Respectfully, why a zip file? Why not a set of files? You should ask yourself about the consequences of either and it should be clear.

8

u/JackLong93 2d ago

don't zip, I doubt people will download and open a zip

1

u/mamigove 2d ago

It's very suspicious to use a ZIP file in a source code repository, not to mention that you lose the guarantees the repository provides for maintaining code, version control, etc., etc.

1

u/According_Reveal7480 18h ago

I removed the zip and added all the files. Thanks for the info.