.lock and author udpates

[samueldr]

It is expected to have many authors that aren't able to merge and or push to this repository, but wanting to update their packages.

The way the AUR works, nothing stops the authors from updating when they want, and everything is updated.

AFAIUI, the current implementation would need a merge to update the lockfile for the specific revision given to get updates from the author.

Would it be advisable to keep the lockfiles for evaluation and search, maybe even as the default installation method, but allow a NUR-tracked overlay to fetch the tip of a branch?

I don't know if there are issues in allowing a NUR-tracked overlay to follow the tip of a branch; as long as they aren't merged with the root it shouldn't matter if $malicious.bash is added, it wouldn't replace any other bash except into its own overlay, right?

[Mic92]

The plan was to update the lock file automatically with a travis-ci cronjob - so it would be ensured that the latest version evaluates. The latency could be improved by triggering build automatically whenever a repository is updated.

[Mic92]

This is faster because with many repository every client would check every 15 minutes if a repository needs an update.

[Mic92]

Since by default nothing is fetch from a repository by clients, malicious code in a repository will not affect users unless they are using the repository.

[samueldr]

Oh, I meant while they are using a repository. $malicious could have had something legit and later added something less than legit. Even trusting all users as not being malicious, $hackable may have been hacked and someone else pushed an update to its popular repository.

Though, security here wasn't my main concern, only update propagation. Since locking is expected to be automated, this is fine.

This can be closed

[Mic92]

Fixed 0721310