public-bin

My junk drawer: https://github.com/peterwwillis/junkdrawer The junk I haven't touched in 10 years: https://github.com/psypete/public-bin/src

Not the same, but you can use two-man crypto verification to make sure a file was signed/encrypted by multiple parties. Example: https://github.com/psypete/public-bin/blob/public-bin/src/se...

First off, I love the philosophy, and the package format is nice. I'm not a language hipster, I don't care what language you write something in as long as it fits the purpose well, and shell can certainly do that here. However, some uses of shell in the package manager are non-obvious, and that will make it more difficult for people to troubleshoot or maintain this code. @OP: I imagine you've examined Slackware's pkgtools? (https://slackware.osuosl.org/slackware-12.1/source/a/pkgtool...) They're written in shell too, and have been in use since 1994. I wish they would get a bit more updated to do things like read metadata (especially for Slackbuilds) and handle build dependencies, but I always found them pretty easy to understand and modify to my needs. Later I threw together some scripts to automate the most common configure/make/make ins

Back when Fetchmail would segfault on certain spam messages, and a bug report to ESR went nowhere, I wrote my own mail fetcher in Perl. Then I extended it to IMAP, and later IMAPS, working around some bugs in some popular IMAP servers. I had it deliver mail to a local mda (so I could use Maildir and mda filters) and configurable to keep or delete mails from the remote server. I think it only supports one remote mailbox, however. https://github.com/psypete/public-bin/blob/public-bin/src/po... (It's very old code that sucks, and not secure, fwiw)

Yep, makes it much simpler to write scripts like this https://github.com/psypete/public-bin/blob/public-bin/src/st... (run an application that's stored in git, but in a temp working directory, and clean up after)

Here's one I wrote a while back that has its own RC4 routine in Perl, so no external dependencies needed. https://github.com/psypete/public-bin/blob/public-bin/src/sy...

Perl modules to implement this would be Date::Manip and DateTime::Format::Natural. To see some funnier modules (like calculating Discordian dates or Japanese eras) look here: http://www.perl.com/pub/2003/03/13/datetime.html I actually bumped up against legacy time/date issues while working on SSL cert parsing. An old Perl interpreter's 32-bit limits kept resetting my dates! Rather than upgrade perl or my architecture, I wrote my own perl methods to calculate infinite time (sorta?) on 32-bit systems with old perls. For those that haven't worked with date parsing before: timezones are surprisingly complex, leap years are stupid, daylight savings is really stupid, and leap seconds are impossible without a regularly updated leap second database (similar to timezones, but worse). (The math to calculate dates correctly is rather simple, but yo

If you want to verify the complete chain or see if any of it is expired, I wrote some tools that'll do just that. It uses a pre-existing directory of CA certs (which you can generate with an included Makefile and cacert.pem) and downloads intermediaries. https://github.com/psypete/public-bin/tree/public-bin/src/ne...

That's weird. Bash_history doesn't usually get flushed for every command you run; only when you exit an interactive shell. If you `kill -9 $$` or erase the .bash_history file and create it as a directory, it loses the history. The exception is if you create a custom PROMPT_COMMAND="history -a; history -n", which would append on each new bash prompt. (You'd think a hacker would know these things...?) As an alternative to dumping history, if your system has perl and strace and you want to watch a live ssh or bash session, I wrote a script that will do that. https://github.com/psypete/public-bin/blob/public-bin/src/sy...

There's a lot of fun to be had with strace. I wrote a tiny perl script that spies on the file descriptors of another process and outputs it to your terminal: https://github.com/psypete/public-bin/blob/public-bin/src/sy...

I threw together an alternative to Red October that only requires bash, coreutils and openssl. Because it uses existing applications there's virtually no risk of the crypto implementation having bugs (or only openssl's bugs, anyway). And because it's so simple you can add whatever functionality you want to fit your system. For example, you can modify it to require a passphrase on the keys; I left it out for simplicity. https://github.com/psypete/public-bin/blob/public-bin/src/se...

First, pick a CM package. This depends entirely upon your level of masochism and the kind of language youlike scripting in, as literally anything will do. Even shell scripts. Even Makefiles. Whatever you're most comfortable with, just start writing out configs. (you will eventually come to hate your job if you allow non-programmers to script/program in your CM, but blah blah keep shipping blah blah) Break it all out intoa wide hirearchy so you can reuse some bits in other bits. Hey look, I wrote a crappy one! https://github.com/psypete/public-bin/tree/public-bin/src/si... Next we implement the OP's comments. Hey look, I already implemented it in my crappy CM tool! https://github.com/psypete/public-bin/tree/public-bin/src/si... First push your CM tool and configs to the host: scp -r simplecfm-0.2 remote-host: Then run the main config fi

A cursory examination of the certificate will appear to be exactly the same as the "real" one, with the exception of lengthy obscure keys and numbers that nobody would identify unless they compared them to the original side by side. The proxy vendor MAY provide its own issuer description in lieu of faking the original, but it by no means has to. Fake certs can look just as authentic as real ones if your browser trusts the root cert that signed them. If you want to verify a certificate is signed by a "real" trusted CA, use a program that traces the chain of trust against a list of CAs that ship with browsers. I have such a tool here: https://github.com/psypete/public-bin/blob/public-bin/src/ne...

/usr/local is a crutch. When you're a user installing software, you don't get to write to /usr/local. You have to use $HOME/usr or something and modify your path. When you're an admin on a box, you can install software anywhere. You could totally './configure&&make&&make install' and your software lands in /usr/local. If you're lucky, there won't be any conflicts with existing earlier versions in /usr. But there's consequences. Now you've built a lot of software and some of it depends on stuff you put in /usr/local. Now you need to upgrade. But is something going to break? What's the compatibility? How can I track what has been installed? Can I uninstall anything? You don't realize how big of a mess you're getting into until you have to remove all of /usr/local just to get some working apps and start from scratch. Take the time to learn t