<div dir="ltr"><div dir="ltr"><br></div><div>> In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt.</div><div><br></div><div>Good point. I'm going to submit it today.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 21, 2021 at 3:57 PM James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 19, 2021 at 4:07 AM Jiri Podivin <<a href="mailto:jpodivin@redhat.com" target="_blank">jpodivin@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>Which brings me to my point. The openstack/requirements does provide one rather essential service for us. In the form of upper-constraints for our pip builds.</div><div>While we are mostly installing software through rpm, many CI jobs use pip in some fashion. Without upper constraints, pip pulls aggressively the newest version available and compatible with other packages.</div><div>Which causes several issues, noted by even pip people. <br></div><div><br></div><div>There is also a question of security. There is a possibility of a bad actor introducing a package with an extremely high version number.</div><div>Such a package would get precedence over the legitimate releases. In fact, just this sort of attack was spotted in the wild.[1]</div></div></blockquote><div><br></div><div>It should be noted however that upper-constraints.txt only applies in CI. If you "pip install python-tripleoclient" in a fresh virtualenv, you get latest releases, assuming they satisfy other dependencies. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Now, nothing is preventing us from using upper requirements, without being in the openstack/requirements projects.</div><div>On the other hand, if we remove ourselves from the covenant, nothing is stopping the openstack/requirements people from changing versions of the accepted packages</div><div>without considering the impact it could have on our projects.</div></div></blockquote><div><br></div><div>This would mean you could potentially have issues pip installing with the rest of OpenStack that have accepted the requirements contract. It goes back to my original point that I don't think we care.</div><div><br></div><div>Overall, I don't get the sense there is broad agreement about this change, and it is not completely understood, myself included here. We should likely hold off on making any decisions until time allows for a more thorough deep dive into the implications.</div><div><br></div><div>In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt.<br></div></div><div class="gmail_quote"><br></div>-- <br><div dir="ltr">-- James Slagle<br>--</div></div>
</blockquote></div></div>