Skip to content
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

Should kernel info be included in notebook signature computation? #12955

Closed
divyansshhh opened this issue Aug 17, 2022 · 1 comment
Closed

Should kernel info be included in notebook signature computation? #12955

divyansshhh opened this issue Aug 17, 2022 · 1 comment
Labels
enhancement status:Needs Triage Applied to new issues that need triage

Comments

@divyansshhh
Copy link
Contributor

divyansshhh commented Aug 17, 2022

Problem

At present, when computing the signature of a notebook, the compute_signature function (ref) takes into consideration the kernel info. I believe this shouldn't be done because it has no effect on the safety of the output.

Proposed Solution

If there is no reason to include kernel info while computing the notebook signature then it should be stripped out.

Additional context

In our use-case we have a custom contents manager that can be used to access notebooks from a remote host in a read-only mode. Now, if the original notebook was authored with say kernel1 then opening that in a host which doesn't have a kernel named kernel1 makes the notebook untrusted.

@afshin
Copy link
Member

afshin commented Aug 18, 2022

I opened an issue in the jupyter/nbformat repo to track this in the relevant repo. Thanks for bringing this up, @divyansshhh. I'll close it here in favor of the nbformat issue.

@afshin afshin closed this as completed Aug 18, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement status:Needs Triage Applied to new issues that need triage
Projects
None yet
Development

No branches or pull requests

2 participants