Release Retention

[digitalsleuth]

I was wondering if there is a chance that you might keep historical releases in the GitHub repo for all major.minor.patch releases (at least for the live major branch), instead of adding all new releases (including patch level changes) to a single major.minor release candidate?

For example, in the current major-release cycle (5) keeping all point releases would be helpful. At this point, for 5.4 only 5.4.5 is available, and anything below 5.4.5 is gone. It would be helpful to have access to a "last known good" candidate in the event that a patch-level release breaks functionality unintentionally.

Additionally, with the fact that this is a great tool, I like to automate my process of building a forensic workstation, and will typically automate the install of software we use to pull a known-good version for each workstation. Part way through a process, if 5.4.4 is deleted (tested and known-good), then 5.4.5 comes out, the automation process is broken and 5.4.4 is no longer available.

Any chance this might be something you'd consider?

[ufrisk]

This is absolutely something I'd consider.

I just have to think about how the best way of doing it would be.

The issue is actually even worse than pointed out. There may be several releases even in the same patch release with only differing dates. The code is guaranteed to be the same within the patch releases though. An example would be today's update which added patch tuesday offsets for April to the info.db database.

I should probably add some off-site archive for older releases. I have it internally already. I'd have to look into how to best do this and integrate it in the build system though.

Also possibly start handling the info.db file in some other way (since it's updated quite often). It's not too much of a biggie having an old version of it though if you have an active Internet connection since there will be a fallback to the Microsoft symbol server in those cases.

In the near future there will be a 5.5 release with some additional findevil detections as well as yara support.

Let's keep this issue open until I've resolved it.

[digitalsleuth]

Well, I'm not sure what your workflow might be, but you can tag and sign the release as it's point release form (ie. 5.4.6) then add the assets to it. This can be automated as well from bash / PowerShell (whatever your flavour), and the previous release (in this case, 5.4) doesn't have to be deleted.

GitHub will also store all of your previous releases as well, as there's a 2GB limit per file in a release, so you can store your releases almost indefinitely.

Your general workflow could be:

• git add
• git commit
• git push origin
• git tag
• git push origin --tags
• generate a release
• Upload / POST your release assets.

The upload could be done manually as well if you prefer. I happen to have a bash script I use for generating and uploading release files to my GitHub that I'd be happy to share if it helps.

• a few POST commands with your GITHUB_ACCESS_TOKEN to the release id

[ufrisk]

I don't wish to spam the releases section every time I update a spelling error or the cached offsets after every Patch Tuesday.

I'll continue update the main releases as I've done previously.

But I agree it's good to have a record of the updates - no matter how insignificant they are. I'll feed all releases and updates into an archive release at https://github.com/ufrisk/MemProcFS/releases/tag/v5_archive

Please let me know if this would fit your requirements?

---

Also, I've just updated MemProcFS to v5.5.

The main news this time is support for Yara in forensics mode (all processes, with minor exceptions, are scanned if a rule is specified on the command line) and in each process.

Also the FindEvil have been remade to a forensics only module. I also added a lot of new detections for potentially evil threads.

[digitalsleuth]

Just saw this now, sorry for the delay. I just want to clarify that I'm not suggesting you change your release schedule or timeline, just that when you generate a new release, you make it a separate release instead of under the umbrella of a major.minor. This way the previous release remains in tact, and the new release gets its own tag.

Currently you're doing almost the same thing, except you're deleting the previous release assets, and adding new ones. Also, keep in mind that you're not really spamming people each time you update a spelling error or cached offsets, you're only updating the release as it exists on GitHub and notifying those that watch the project that a new release is available.

As for the archive, that will definitely fit the requirements mentioned in the initial request, but it may end up being a bit more effort on your part if you need to not only add a new release, then add the previous assets to an archive. Either way, this does achieve the recommendation.

Thanks for your patience, and assistance!

[ufrisk]

Awesome to see this issue is now resolved.

Please let me know if you should run into any issues in the future or if you wish for me to look into adding any new features and I'd be happy to help :)