Skip to content

[spike] thamos integration of rekor #262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
goern opened this issue Dec 7, 2020 · 10 comments
Closed

[spike] thamos integration of rekor #262

goern opened this issue Dec 7, 2020 · 10 comments
Labels
kind/demo This is an Issue or PR someone want to give a demo or request a demo. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@goern
Copy link
Member

goern commented Dec 7, 2020

can we create a "rekor indicator" that will tell the developer that a python module being used in an advice has valid rekor information

As a user of Thoth,
I want to see a "rekor indicator" with my thamos advise response,
so that I can understand if the releases that are in my dependencies are authentic

As a Python Index Operator,
I want to run a side car rekor service,
so that developers/publishers can put their module release information in it

As a Python Module Publisher,
I want to publish my module on a Python Index,
and I want to add my release signature to rekor,
so that thamos can use it within an advise

Cc: @lukehinds

References

@goern goern changed the title [spike] can we create a "rekor indicator" that will tell the developer that a python module being used in an advice has valid rekor information [spike] thamos integration of rekor Dec 7, 2020
@goern
Copy link
Member Author

goern commented Dec 7, 2020

@fridex could you have a little look at this? if feels like Luke might have some nice additional tooling that we can put alongside the SI to have a very strong provenance of dependencies

@fridex
Copy link
Contributor

fridex commented Dec 7, 2020

It might be good to refresh the discussion with upstream. Wheel files can be signed and wheel had the capability of performing such checks. IIRC, pip performs checks respecting PEP-491 during the installation process. Unfortunately, the support for signed wheel files was dropped in wheel - see pypa/wheel#196. It might be good to refresh the discussion and see the current position of PyPA to this so we eventually and ideally end up with a standardized solution.

@fridex
Copy link
Contributor

fridex commented Jan 4, 2021

There has been already upstream issue which is currently WIP - see PEP-458 and the related PR (pypa/pip#9041) which supports package signing when installing packages from PyPI. I think it might be good to get insights from the community on this topic (https://discuss.python.org/t/rfc-improving-pip-security-with-package-signing-pep-458/5713) - how to manage signed packages outside of PyPI in case of self-hosted package indexes. It looks like the support could land in pip and PyPI.

@goern
Copy link
Member Author

goern commented Jan 5, 2021

@lukehinds the PEP-458 effort seems to be the right place to integrate rekor into the python toolchain. rkor seems to be an alternative to what the python community wants to do right now, so its worth working with them to think about rekor.

@fridex
Copy link
Contributor

fridex commented Jan 14, 2021

If there is a plan to integrate rekor into pip/Python, it might be a good idea to get involved in the community efforts. It looks like they are planning to design signing in a specific way. See https://discuss.python.org/t/rfc-improving-pip-security-with-package-signing-pep-458/5713/4

@sesheta
Copy link
Member

sesheta commented Apr 17, 2021

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@sesheta sesheta added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 17, 2021
@goern
Copy link
Member Author

goern commented Apr 19, 2021

/remove-lifecycle stale

@sesheta sesheta removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 19, 2021
@goern goern added kind/demo This is an Issue or PR someone want to give a demo or request a demo. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Jun 10, 2021
@sesheta
Copy link
Member

sesheta commented Jul 15, 2021

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

@sesheta sesheta added the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Jul 15, 2021
@sesheta
Copy link
Member

sesheta commented Aug 24, 2021

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

@sesheta sesheta closed this as completed Aug 24, 2021
@sesheta
Copy link
Member

sesheta commented Aug 24, 2021

@sesheta: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/demo This is an Issue or PR someone want to give a demo or request a demo. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
None yet
Development

No branches or pull requests

3 participants