brenekh / blinky Goto Github PK

I have an project written in Golang which is for building pacman repository, which is Hayao0819/ayaka

Now, ayaka has no functions to update db and upload it but has building package with devtools so your blinky has what my tools does not have.

What I would like to do is calling blinky from my ayaka through golang module. I am going to read blinky packages and implements it on my ayaka.

However, from Readme, blinky does not support another architecture. Could I ask you how to use it on multi architecture, x86_64 and pentium4 ?

JSON is fine for testing and small scale deployments, but a more robust key-value store should be used to make Blinky more robust.

Badger looks like a good candidate for this job.

If an admin wanted to, they should be able to require that a package be uploaded with a proper signature.

Optionally, the key could be verified by a web of trust local to Blinky. However, this may present more problems than solutions because setting up the web correctly will more than likely be hard to do.

Blinky does not automatically create the database files when creating a repository for the first time. The user needs to upload a package before those files are created.

This means that pacman will fail to pull the DB for an empty repo, because the DB files don't exist and Blinky can't serve them up.

My thought is that the only information that needs to be provided for removal is the package name.

If a key-value database is kept which contains the package name and the file that was uploaded for it, that can be used to identify the file that needs to be removed for a given package name, which greatly simplifies the API spec.

Currently the API just takes the client at face value when it gives the package name to use for file association in the Blinky database. (repo-add parses the package and uses the name in the file) This obviously could lead to issues, maybe even security problems if one were to use a misbehaving client.

The solution is to move the name extraction to the server and use the name inside of the *.pkg.tar.zst instead. This also lays some groundwork for parsing the architecture and sorting the package into the correct "sub" repository.

While performing this change, it also makes sense to change the API so that uploading a package is just PUT /<repo name>/package instead of PUT /<repo_name>/package/<package_name>, as it makes more sense if the server is no longer relying on the client for the package name.

This should allow both signed and unsigned packages to be added to a repository.

Because signed packages require both the .pkg.tar.zst and the .sig files, the multiple file upload feature of HTTP Form Data will need to be leveraged as part of the API spec.

I'm not sure how to make this work for both native and Docker installations, but a signed DB is almost a requirement of any serious software repository so it needs to be done in one way or another.

Currently users of the API have to provide the API key set by the server owner in the Authorization HTTP header.

This approach is confusing for the user and doesn't allow the CLI to use one method to authenticate for both the integrated and possible third-party auth providers.

A better option is to allow the server owner to set both a username and a password. Then HTTP Basic Authentication can be used which will also allow third party auth solutions to work well.

Instead of specifying a single repo path in $BLINKY_REPO_PATH, multiple should be allowed using the same separator used for $PATH.

By using /repo/<repo_name> the root path can be reserved for future uses, and repo names such as api won't interfere with those paths.

Currently, there isn't a great way to upload and remove packages from Blinky. curl commands will technically work, but there should be a more intuitive way to go about these tasks.

I'm thinking of a blinky cli tool that will be able to login to various servers and upload/remove packages.

The configuration toml file locations are hardcoded and cannot be set, but ConfigDir makes it sound as though that is modifiable.

ConfigDir is actually used for the database so a more appropriate name would be DataDir.