My thinking in the early days was that the StarlingX build was a build for developers. In order to facilitate contributions to StarlingX, we needed allow folks to build and install packages signed with the same common set of developer credentials. Anyone looking to do a real world deployment was expected to rebuild the full load, substituting their own credentials, or employing a signing server. At the next community meeting, we should switching to a secure set of credentials for our release branches. Or perhaps having two builds, one with secure creds and one with the current developer creds. Scott
CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi StarlingX community,
Someone reached out on the info email for the project to raise a concern about exposed credentials in the starlingx-staging repo in the jenkins folder.
The person listed a few items that might be of a concern to be stored in the public repository: * base64-encoded client certificates and private keys * Cluster configurations referring to kubernetes-admin access * Kubernetes API endpoints
While these are likely out of concern due to describing a test environment, but I wanted to share the concern if it might still be helpful to look into.
Best Regards, Ildikó
———
Ildikó Váncsa Director of Community Open Infrastructure Foundation