warning: local is newer than core

seth · Yesterday 06:34:06

There are *always* going to be (temporarily) bogus mirrors around - using tools like reflector helps you to stay away from them but cannot even provide a perfect shield.

For this to become a thing you *need* to have realized that you've been using a bogus mirror and at that point you *need* to use -Syyu and nobody's allowed to chastise you for that.
That's part of the regular system maintainance.

Sure it'd be nice for the mirrors to change their behavior but in reality could be tedious to get them to (mail and convince everyone of them) and there can be ulterior motives precluding other behavior (since the mirrors often don't just mirror arch but all sorts of stuff™)
So while the mirrors should change, https://www.youtube.com/watch?v=5RyYrs5tu60

Beemo · Yesterday 09:41:04

You almost convinced me there... I was about to change pacman.conf to use only geo.mirror.pkgbuild.com and tell anyone the same in the future.
But then I remembered we (or any other distro) never trusted anyone to begin with, that's why there are package signatures, to make sure we don't get served bogus data. That's how security always have worked.
"--remote-time" is a piece of unauthenticated data that is blindly trusted by pacman and affects its behaviour.

but in reality could be tedious to get them to (mail and convince everyone of them) and there can be ulterior motives

We never needed to beg the servers to do the right thing. We can just patch the bug so that those that fail the verification get rejected. No doubt it's a solved problem in some other distros. (Maybe look at Fedora?)
Now in practice it's probably going to take some work if there isn't an easy way to patch it in Arch.

you *need* to have realized that you've been using a bogus mirror

That's probably too much to ask of the users.

Last edited by Beemo (Yesterday 09:45:45)

cryptearth · Yesterday 10:23:36

i somewhat have the itch to ask

@OP
do you have issues with one specific mirror?
or do you try to parallelize accross mirrors?

as it was explained: unless you as the user change the active mirror you should never encounter such issue unless the mirror is acting really weird
but getting that issue hints towards you likely changed from a mirror that sync more recently to one whose last sync is older - which begs the question: why you so in the first place?

"uncommon network" - are you talking about the mirror? if so: how do you know? or are you talking about your own network?

to counter your passive agressive: there're just too many thinks in this topic that doesn't add up to eachother - which makes it not useful as a big report basis

to me this topic once again looks like so many others: must be something on your end - as neither i nor so many others experience these issues
if it would be something remote you would not the only one affected

or to put it this way: in order to actually help you we still need more information than you provided yet - and at least for now we keep asking
if you fibd that already uncompfortable we could just go silent and wait for you spam the next two pages until something popsup someone still following can actually get on with

Beemo · Yesterday 10:38:21

https://youtu.be/UyvFiG1K0W0?t=95

seth · Yesterday 14:00:20

* I didn't know that Fedora was a rolling release distro…
* It's not being asked from users to understand that they're using a bogus mirror - the understanding is rather what sparks your scenario itfp.

We can just patch the bug so that those that fail the verification get rejected.

Who is we? You're asserting realities w/o providing any details.
"We" cannot "fix" any mirrors and "make me a sandwich or you'll no longer be allowed to give me blow jobs" is not how reality works.
The idea to lose like 50% of mirrors because they're not adjusting to what you claim to be a theoretical(?) problem sounds rather crazy.

Databases are currently not signed for several reasons, https://wiki.archlinux.org/title/Develo … DB_Signing (spoiler, it's not as easy as you probably think it is - the databases are essentially mirror-specific)
They're inherently untrusted (which in and by itself is not a problem - the menu of a restaurant might only offer poisoned food, as long as you know it's poisoned you won't eat it and probably stop frequenting that restaurant)

It would theoretically possible (though pot. break ALPM compatibility, arch isn't the only user of that format) to put a timestamp into the database (when signing; you've a reliable datapoint but see above).
You'd then unconditionally download database or meta-timestamp and check its content instead of relying on the http mechanism, but this will cause traffic overhead (notably when using the database directly) and the question remains:
=> what will be the benefit of that, ie. how much of a real life problem is this, the user will still have to deal w/ the reality that they might be using a stale mirror.
You've avoided to address that.

mpan · Yesterday 22:09:44

The thread landed at arch-mirrors@list.archlinux.org, if anybody wishes to follow it there.

Arch Linux

#26 Yesterday 06:34:06

Re: warning: local is newer than core

#27 Yesterday 09:41:04

Re: warning: local is newer than core

#28 Yesterday 10:23:36

Re: warning: local is newer than core

#29 Yesterday 10:38:21

Re: warning: local is newer than core

#30 Yesterday 14:00:20

Re: warning: local is newer than core

#31 Yesterday 22:09:44

Re: warning: local is newer than core

Board footer