Replaced the current nwipe.mk download option by a git submodule, poi..

[Knogle]

…nting to master branch.

Ahoy.
I have used this approach to build my ShredOS release from the aes-ctr branch more easily.
The submodule always points to master, so it's easy exchangable, in my opinion more easy than have to download a release package etc.

[PartialVolume]

This might be a good idea from a developers perspective for ease of testing but from a users perspective being restricted to a official release of nwipe is safer in my opinion, in that the master is for developers and may have had limited if any testing so I wouldn't really want users using the master in ShredOS only a official release, or making it easier to switch branches. At least using the buildroot method it does verify the download with a hash. I'm unclear what protection git sub modules offer against man in the middle attacks.

I test a branch by issuing a release from my fork then calculating the hash and changing the URL in the .mk and the hash. Maybe more time consuming than just editing a URL and branch in the .mk file but purposely makes it a little more difficult to build from the master for good reason so users don't do it.

I do appreciate how it does make it easier for the developer though to link to their fork and branch without having to deal with releases and hashes.

I will have a think about this.

[Knogle]

Ahhh understood, valid points, what do you think about something in the buildroot to switch between stable, and master like in many buildroot-based projects?
I could add that in this PR.
It's also possible to lock the submodule for a specific commit in the nwipe.mk file, e.g. the releae commit.

[PartialVolume]

Ahhh understood, valid points, what do you think about something in the buildroot to switch between stable, and master like in many buildroot-based projects?

Yes, that could work. From the developers point of view making it easier to switch and point to different URLS and branches would certainly make testing a branch easier for the tester/dev. But at the same time having the existing hash based download for nwipe for production use and final release is a must.

[PartialVolume]

It's also possible to lock the submodule for a specific commit in the nwipe.mk file, e.g. the releae commit.

I'm not clear on what you mean here. If I understand correctly, wouldn't this still have the issue of not checking the integrity of the download. i.e no hash, so man in the middle and corruption susceptibility issues. Not too important for developers but for production use the source download needs to be verified for it's integrity.

However, like I mentioned in the previous post a simple switch somewhere that allows the developer to easily switch between git sub module and standard buildroot hash would be a good thing. Then edit the URL and branch in the .mk would be a nice update.

[Knogle]

Ahoy.
Yeah It's checked for integrity. As it's the same process as cloning a git. So there will be HTTPS traffic with TLS etc. also after cloning it checks the cloned data for integrity. Each file is SHA-1 hashed, and the commits are signed.
So it does basically the same, but uses git internal functions to accomplish this.

[PartialVolume]

Ok, if you can implement the switch, so the dev can switch between the two methods I can then test your RC4 branch at the same time on some older hardware.

[Knogle]

Ok, if you can implement the switch, so the dev can switch between the two methods I can then test your RC4 branch at the same time on some older hardware.

Ahoy, i think i can do it but tuesday next week only, as i will leave for vacation now over the weekend.
But for the RC4 branch you could change the .gitmodules file, and put the rc4 branch in there manually until i got the changes in :) And run git init submodule afterwards.

[Knogle]

Please check my new branch. I have implemented as requested, but didn't test yet.
https://github.com/Knogle/shredos.x86_64/tree/switch-submodule-release
Unter Packages --> Libraries --> Other --> Nwipe you can select whether you want to use the old approach or git.
Also updated the defconfig, in order to default to the legacy download of the release package.

When opting for git you can specify the details, default is the release commit of the packaged version.

But as mentioned, this one isn't tested yet.

[PartialVolume]

Nice work!, I'll test that out and get back you.

[PartialVolume]

Quick question. can you explain why the commit number is needed? Would it generally point to the last commit in the branch?

[Knogle]

Quick question. can you explain why the commit number is needed? Would it generally point to the last commit in the branch?

Oh hey! I wanted to lock to the commit that's used for the release packing by default. But I can change this behaviour as well.
So when you change between release and git version and change nothing else, the result will be the same.
If you leave it empty, it will refer to HEAD, so the latest commit.

[PartialVolume]

Needs debugging, there's a couple of path errors re patching ../../ should be used instead of ../../../ for the sub module section re patch file locations? File permissions 003-nwipe-banner-patch.sh needs execute permissions and it looks like it tries to apply the patch before any source has been downloaded. I'll let you work on that next week :-)

[Knogle]

I will continue the debugging during next days :)
In case of my fork i am currently using Yocto in order to build the distro and the images, it's very versatile, and it's very easy to have different recipes for efi, hddimg, eltorito-iso etc., when it's done i can show you, maybe it's interesting as well for a contribution here. And very easy and clean to handle external ressources.