search

DelphiPackageManager / PackageManagerRFC

Delphi Package Manager RFC
Apache License 2.0
30 stars 0 forks source link

Package MetaData #6

Open vincentparrett opened 5 years ago

vincentparrett commented 5 years ago

Each Package file will contain a Metadata file (probably xml), which describes the package, what it is, where it comes from, what it contains etc.

These are the informational fields I have so far :

Name Version Copyright IconUrl LicenseUrl ProjectUrl Description Summary ReleaseNotes Tags RequireLicenseAcceptance IncludesSource PreCompiled IsPreRelease IsEvaluation IsCommercial Compiler/Platforms - TBA

The meta data file will also contain information about the file structure, what folders need to be added to the search path for each compiler/platform combination, whether there are any runtime or design time packages that need to be deployed etc. The metadata will also detail the dependencies the package requires, such that the client can ensure the dependencies are available and install them before installing this package.

casteng commented 5 years ago

Name is an identifier also? So it should be unique? Metadata format version may also be useful.

code-kungfu commented 5 years ago

In addition to what @casteng mentions, wouldn't it be an idea to include a field with a GUID or uniquely identifiable hash in case a faulty or compromised package has been published to the registry?

vincentparrett commented 5 years ago

Package Authenticity is something I'd definitely like to implement. We'd likely implement something similar to nuget's package signing

https://docs.microsoft.com/en-us/nuget/create-packages/sign-a-package

This requires that package authors have a code signing certificate.

I'm not a fan of guid's for identity, you can only tell by comparing them if it's correct (don't know about others but I don't memorise them). As I mentioned in the blog post, once we have a public package registry, authors will be able to reserve names and prefixes, so for example TMS could reserve the TMS. prefix, then no one else would be able to publish a package starting with TMS. (e.g TMS.MyFakeGrid).

vincentparrett commented 5 years ago

This is how nuget handles package identity

https://docs.microsoft.com/en-us/nuget/reference/id-prefix-reservation

andersmelander commented 5 years ago

In my own package manager an author is assigned a unique ID and a set of public/private keys when they register. In addition they must supply a unique human readable name that is tied to the ID. The AuthorID is used across all products released by that author but is never seen by the end user - they just see the author name. The private key is used to sign the product on upload and is only stored on the authors system. The public key is used to verify authenticity and integrity of the downloaded products. Same with products. Each product is assigned a server assigned unique ID and an author specified human readable name.

The ID/name system gives the authors the ability to rename themselves (or fix a typo) and their products without invalidating everything that's already been released. In my case the ID is based on a scrambled sequential number assigned by a server but it could just as well be an author specified unique string. Oh, and the ProductID is generated in such a way that the client can verify that it does indeed belong to the specified AuthorID without having to ask the server (which of course would know).

AFAIR I originally used the Mozilla extension ecosystem as inspiration.

Wrt. IconUrl I think I would prefer the icon to be included in the package since presumably it would always be used when installing via the GUI. Better to keep the package self contained IMO.

wlandgraf commented 5 years ago

Why not using JSON as the package descriptor format, it's more readable than XML.