8000 How must the persistent cache work? · Issue #723 · gittuf/gittuf · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

How must the persistent cache work? #723

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.

Sign up for GitHub

By clicking “Sig 8000 n 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

Jump to bottom
Open
1 task done
adityasaky opened this issue Jan 8, 2025 · 2 comments
Open
1 task done

How must the persistent cache work? #723

adityasaky opened this issue Jan 8, 2025 · 2 comments
Labels
discussion This needs further discussion and feedback

Comments

@adityasaky
Copy link
Member

Add a description

#716 (related to #245) introduces a persistent cache that tracks:
a) all policy entries in the repo
b) all attestations entries in the repo
c) the last verified entry for a particular ref

There are several open questions still regarding how the cache must operate to avoid unexpected / surprising behavior from the users' pov.

  1. Should a user opt into using a persistent cache, perhaps via a gittuf.usePersistentCache option in their git config? Alternatively, should such an option be to opt out of using the cache?
  2. Should the user have a flag (e.g., --ignore-cache) to not use the cache during verification?

Relevant log output if the discussion pertains to existing gittuf functionality



Code of Conduct


    

  •  I agree to follow this project's Code of Conduct
    • 


      		
    

      
  





        



            
            

              
            

        

      


      
    








      

    



      

  
            

    

      
    

    


      

          @adityasaky
adityasaky




          added
  the 

  discussion

  This needs further discussion and feedback
 label


      Jan 8, 2025

    

  








      

  
      



  

  @adityasaky





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
  Member


      

  Author


  


  
    

  




      


        


  
    

      
          
I am personally leaning towards:


    

  1. require users to opt-out rather than opt-in via a git config option
    2. 

  2. yes, there must be a way to avoid using the cache when invoking gittuf verify-ref
    3. 


      		
    

  





        


            

            
            

              
            

        

      


      

            
  
  

    
  
    
    

  

  

  


    












      

  
      



  

  @adityasaky





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
  Member


      

  Author


  


  
    

  




      


        


  
    

      
          
Also, copying @JustinCappos's comment #245 (comment):




Right. I agree having a local cache of such information is sensible.


In my view, so long as we end up with a solution that does not introduce any vulnerabilities / issues regardless of the repository / other user behavior, this is a positive.


One other thing we may want to consider is that a user may want to receive this information from another device for some reason. I think a sensible reason for doing so is when a user moves to a new laptop, they may not want to redo all of the checking for each of their repos. While this may happen naturally if they copy all file system state over, it may not happen in other cases. It could also (in theory) be the case that for a large repo like the Linux kernel, one decides to go from some later verification point which has been validated by a very large number of people you trust. (I'm not arguing this is a good model in all cases, I'm just saying that people will want this to happen, I think.)




The cache as it is implemented is just a file on disk that could be easily moved over. I think using someone else's cached states is interesting, and perhaps ties into #190 as well to bootstrap trust for the cache itself?

      		
    

  





        


            

            
            

              
            

        

      


      

            
  
  

    
  
    
    

  

  

  


    
















  
  

    

      

  





  




  
  

              

  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment


  



  






  
                  




    

  


      
  

    Assignees
  



        

    No one assigned







      


  


  

    Labels
  



    

      

    discussion

  This needs further discussion and feedback








      

  

    

        

    Projects
  


        




    None yet




  



      


  

    
  

    Milestone
  


      No milestone





    
      
          


  

    

      
        

          
    

    Development
  




            
    
No branches or pull requests







      
    

  




      

    

  
      

  

    

      1 participant
    

    

        
          @adityasaky 
    

  






    

    




    






  

          

        



    



  





    

  


  


          



    



  

    

    

    





    


    

    

  



0