public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Dominic Sacré" <dominic.sacre@gmx.de>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	linux-rt-users@vger.kernel.org
Subject: Re: Changing checksums of RT patches
Date: Tue, 28 Feb 2017 19:03:29 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1702281856310.4732@nanos> (raw)
In-Reply-To: <20170214135738.366f21e5@gandalf.local.home>

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

On Tue, 14 Feb 2017, Steven Rostedt wrote:
> On Tue, 14 Feb 2017 19:42:35 +0100
> Dominic Sacré <dominic.sacre@gmx.de> wrote:
> 
> > Could this be the cause of your issue?  
> > 
> > I think so. Looking at the current contents of rt/4.1, I see that
> > patch-4.1.38-rt45.patch.gz and older/patch-4.1.38-rt45.patch.gz have
> > different sha256 hashes. I would have expected them to be copies of the
> > exact same file, so I guess the question is why they're different in the
> > first place.
> 
> It's the way kernel.org does the updates. I upload a .xz file and a
> signed gpg file of the uncompressed image. kernel.org creates the gz
> file from the uncompressed version. As I upload it twice, kernel.org
> does two gzips of the uncompressed file. I'm guessing that there's a
> timestamp that gets used as well, making both gzipped files different,
> even though what they contain are the same.

Right. And it does not matter at all.

The sha256 tells you that the file you downloaded is the one which
kernel.org advertised to you. Not more, not less.

The content is protected by the *.patch.sign and *.tar.sign files.

> I may need to change my workflow to simply delete the file in the
> current directory than to move it.

And the point is?

> Although, I had better make sure that there's a copy in the older
> directory first. Maybe I'll change my tool to download the older and
> current versions, uncompress them, make sure they are the same, and if
> they are, remove the current version, else, move the current version on
> the older one.

That does not make any sense.

The proper thing to do is move file from rt/4.x/ to rt/4.x/older.

If kernel.org decides to redo the archives, then you can't do anything
about it. And if you upload it another time there is no guarantee either
that the resulting gz/xz are the same.

What matters is the content and not the compressed thingy. Again:

 - The sha256 only tells you that the download was not corrupted.

 - The PGP signature is what protects the content and that does not change
   whether you move it or upload the same thing again.

Thanks,

	tglx

  parent reply	other threads:[~2017-02-28 18:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09  9:09 Changing checksums of RT patches Dominic Sacré
2017-02-10 18:54 ` Sebastian Andrzej Siewior
2017-02-13 22:56   ` Dominic Sacré
2017-02-13 23:15     ` Dominic Sacré
2017-02-14 14:18       ` Steven Rostedt
2017-02-14 18:42         ` Dominic Sacré
2017-02-14 18:57           ` Steven Rostedt
2017-02-15 13:38             ` Dominic Sacré
2017-02-15 13:52               ` Sebastian Andrzej Siewior
2017-02-15 14:50                 ` Dominic Sacré
2017-02-15 17:15                   ` Sebastian Andrzej Siewior
2017-02-28 18:03             ` Thomas Gleixner [this message]
2017-02-28 18:30               ` Steven Rostedt
2017-03-10 23:13               ` Dominic Sacré
2017-03-10 23:19                 ` Steven Rostedt
2017-03-11  2:27                   ` Julia Cartwright
2017-03-11  3:21                     ` Steven Rostedt
2017-03-11 11:14                     ` Dominic Sacré
2017-03-11 13:42                       ` Steven Rostedt
2017-03-11  9:45                   ` Thomas Gleixner
2017-03-11 13:43                     ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1702281856310.4732@nanos \
    --to=tglx@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=dominic.sacre@gmx.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox