Re: crc not installed but rsync using it? ...
On Tue 29 Sep 2020 at 15:50:35 (+0200), Albretch Mueller wrote:
> On 9/24/20, Reco <recoverym4n@enotuniq.net> wrote:
> > On Thu, Sep 24, 2020 at 05:50:16PM +0200, Albretch Mueller wrote:
> >> >> How do I get all packages to be locally installed using dpkg from a
> >> >> public Windows machine?
> >> >
> >> > I'm not sure I understand this question or how it relates to the
> >> > previous one.
> >>
> >> How do I get the deb files in order to install locally (via dpkg
> >> --install) the necessary utilities to run CRC32 and/or CRC64
> >
> > Typical Debian install has perl already, so you don't have to install
> > anything - [1].
> >
> > [1] http://billauer.co.il/blog/2011/05/perl-crc32-crc-xs-module/
>
> But I don't see anything when I go:
>
> which crc, crc32, crc64 ...
Imagine you did find an executable called crc32. What would you do
with it?
You find some data that's in an archive file called foo.zap. The
program zap claims to include a crc32 check within the archive.
Do you expect to type crc32 --check foo.zap and get some
meaningful output, or what?
On Tue 29 Sep 2020 at 15:48:09 (+0200), Albretch Mueller wrote:
> On 9/26/20, Michael Stone <mstone@debian.org> wrote:
> > On Sat, Sep 26, 2020 at 02:11:30PM +0200, Albretch Mueller wrote:
> >>On 9/25/20, Michael Stone <mstone@debian.org> wrote:
> >>> Just one would be good enough (pick the sha256sum). What you're doing is
> >>> a waste of time. If you want to future proof then use sha3, via the
> >>> rhash package.
> >>
> >> Something that I have noticed is that texts are too close to people's
> >>hearts to expect for people to just be technical about them. I use
> >>those three algorithms because some people "understand", md5 and not
> >>sha###sum. I mean, you may get some legacy data with their md5sum but
> >>the maintainers of the data may not be around. Once I found an rsync
> >>log that included the CRC signatures, that is why I include these
> >>kinds fo algorithms.
> >
> > Sorry, still makes no sense and is a waste of time. You're creating new
> > hashes right now, it doesn't matter if someone else might have made some
> > other hash some other time.
>
> But how could you have some assurance that that data relates to what
> their users thought of to be?
You can't. That's not what CRCs are for. They're not cryptographic,
so they are useless for any type of assurance that the data is intact.
Anyone modifying the data merely has to recalculate a new CRC and
substitute is for the original.
CRCs are a quick check on data segments when you're transmitting
segments of a file. If a CRC doesn't agree with its segment, you
ask for its retransmission. At the end of the transfer, you might
do a final CRC check on the whole file, for speed, but it would
be pointless to keep the number, as compared with checking the
file's MD5/SHAnnn digest if that had been archived. That's why
md5sum and shaNNNsum have a -c option.
Cheers,
David.
Reply to: