5 AM
Subject: [Bug 7566] "SHA1 verification failed" for sa-update.razx.cloud
since 1-2 weeks
To: d...@spamassassin.apache.org
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7566
Kevin A. McGrail changed:
What|Removed
Is Dave Warren on this list? If no response, does anyone have an old
email with his contact info so I can ask him how his rsync's are setup?
Dave
On 03/19/2018 08:26 AM, bugzilla-dae...@bugzilla.spamassassin.org wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7566
Dave Jones chang
I found an email address in the SA archives from 2013. Hopefully this
makes it to him.
On 03/19/2018 08:33 AM, Dave Jones wrote:
Is Dave Warren on this list? If no response, does anyone have an old
email with his contact info so I can ask him how his rsync's are setup?
Dave
On 03/19/2018 0
Howdy. I'm on this list.
Okay, so this is a bit odd, it looks like the file 1827131.tar.gz was
actually modified by rsync many hours after the initial write:
Date: Sun, 18 Mar 2018 02:36:30 -0600 (MDT)
.d..t.. ./
>f+ 1827131.tar.gz
>f+ 1827131.tar.gz.asc
>f+ 1827131
I would guess you caught it mid copy and it arose because of the caching.
Just a guess but glad we know what's going on.
On Mon, Mar 19, 2018, 15:09 Dave Warren wrote:
> Howdy. I'm on this list.
>
> Okay, so this is a bit odd, it looks like the file 1827131.tar.gz was
> actually modified by rsyn
I'm going to keep a close eye on it for the next few days manually, and
then decide if adding automated validation is worthwhile or not.
Could you (whoever is responsible) add me back to the mirrors list?
On 2018-03-19 13:36, Kevin A. McGrail wrote:
I would guess you caught it mid copy and it
On 03/19/2018 02:50 PM, Dave Warren wrote:
I'm going to keep a close eye on it for the next few days manually, and
then decide if adding automated validation is worthwhile or not.
I enjoy this kind of scripting challenge so I may do this anyway just so
we know if there are sa-update logs wit
Interestingly the file really is changing and wasn't just a poorly timed
copy, check this out:
Date: Mon, 19 Mar 2018 02:38:08 -0600 (MDT), the files were created:
.d..t.. ./
>f+ 1827165.tar.gz
>f+ 1827165.tar.gz.asc
>f+ 1827165.tar.gz.sha1
And the .sha1 hash valida
Not sure what you mean. Original ticket was about 1827131.tar.gz
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Tue, Mar 20, 2018 at 1:10 PM, Dave Warren wrote:
When I first set up my mirror, I was told "Because the items are release
artifacts, they are never altered or removed, just added.", so I
configured my caching around this design. This does not seem to be the
case in general, it wasn't just a one-off problem on 1827131.
Looking at the original
That is an interesting question because you are right, they are supposed to
be immutable. Dave, is something happening in an 18 hour window as he
describes?
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.link
On 20 Mar 2018, at 14:19, Kevin A. McGrail wrote:
That is an interesting question because you are right, they are
supposed to
be immutable. Dave, is something happening in an 18 hour window as he
describes?
I'm not Dave, but I can see that interval in commit messages. Times are
UTC-4:
Fr
Or creating it in a temporary location knowing it will be changed later.
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Tue, Mar 20, 2018 at 2:45 PM, Bill Cole <
sa-
On 03/20/2018 01:19 PM, Kevin A. McGrail wrote:
That is an interesting question because you are right, they are supposed to
be immutable. Dave, is something happening in an 18 hour window as he
describes?
From what I learned trying to reconstruct everything about 10 months
ago there are 2 up
On 2018-03-20 13:27, Dave Jones wrote:
On 03/20/2018 01:19 PM, Kevin A. McGrail wrote:
That is an interesting question because you are right, they are
supposed to
be immutable. Dave, is something happening in an 18 hour window as he
describes?
From what I learned trying to reconstruct ever
On 03/20/2018 02:59 PM, Dave Warren wrote:
On 2018-03-20 13:27, Dave Jones wrote:
On 03/20/2018 01:19 PM, Kevin A. McGrail wrote:
That is an interesting question because you are right, they are
supposed to
be immutable. Dave, is something happening in an 18 hour window as he
describes?
Fr
On 20 Mar 2018, at 16:18, Dave Jones wrote:
[...]
I thought they were different numbers. They should be. The SVN
version number is shared across all Apache projects using SVN so hours
later there should be a different SVN commit number between the tick
and tock.
But mkupdate-with-scores do
On 03/20/2018 06:18 PM, Bill Cole wrote:
On 20 Mar 2018, at 16:18, Dave Jones wrote:
[...]
I thought they were different numbers. They should be. The SVN
version number is shared across all Apache projects using SVN so
hours later there should be a different SVN commit number between the
tic
Until we have a good score file, while publish the file anyway? DNS should
stay with the last known good file.
I would generate the tick file some where temporary, then update it with
the tock data and publish/update DNS.
The mirrors shouldn't even see the temporary file.
Thoughts?
KAM
That
-
This seems to make sense from here (as a sysadmin. As a mirror operator
I don't care).
On 2018-03-26 14:46, Kevin A. McGrail wrote:
Until we have a good score file, while publish the file anyway? DNS should
stay with the last known good file.
I would generate the tick file some where temporary
On 26 Mar 2018, at 16:46, Kevin A. McGrail wrote:
I would generate the tick file some where temporary, then update it
with
the tock data and publish/update DNS.
The mirrors shouldn't even see the temporary file.
Thoughts?
I don't think the current model is seriously harmful, since the score
21 matches
Mail list logo
