The feature of golang having source in a project path with "internal"
makes the code only able to be imported by the project itself.
https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit?tab=t.0
Since we have this carried version of `archive/tar` with our byte
accounting patches, it is also means the version of archive/tar has not
kept up with upstream.
our tar-split libraries do not even utilize all the function calls of
our carried archive/tar, so might as well limit anyone else in the world
from calling them as well.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Fixes#65
if the read bytes is 0, then don't even create the entry for that
padding.
This sounds like the solution for the issue opened, but I haven't found
a reproducer for this issue yet. :-\
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Previously, we would read the entire padding in a given archive into
memory in order to store it in the packer. This would cause memory
exhaustion if a malicious archive was crafted with very large amounts of
padding. Since a given SegmentType is reconstructed losslessly, we can
simply chunk up any padding into large segments to avoid this problem.
Use a reasonable default of 1MiB to avoid changing the tar-split.json of
existing archives that are not malformed.
Fixes: CVE-2017-14992
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Have a bit-bucket FilePutter, for when it does not matter.
Beginning thoughts on disassembly, but it has things that need thought.
Mostly comments in the function for now.
