Fixes that may break compatibility

[Julio Merino]

Hello all,

We just found out that Bazel's network sandboxing feature on macOS has been broken for an unknown period of time (as #10068 explains). Sandboxing is enabled by default in Bazel.

Now, fixing this specific issue seems pretty easy and we can get a fix ready soon. However, fixing this bug can break builds: if a user's build has gained a rule that performs network access and they are still building with sandboxing enabled (the default), then such build will break after the fix.

I think this specific type of breakage is unlikely to be a problem in the wild: I can imagine most users building on Mac will also be building on Linux, so this restriction will have already been enforced; and many other users currently disable sandboxing on Mac due to its poor performance.

But... any thoughts on how we should handle this specific issue?

And more importantly: any guidance on how to handle similar issues regarding the breaking changes policy?

Thanks

--

jmmv.dev

[Kyle Cordes]

This is a fairly frequent challenge that comes up for projects using semantic versioning. Does a bug fix which would cause breakage for code which (perhaps inadvertently, or even intentionally, for a security fix!) relied on the bug to work, constitute a breaking change and therefore need a major version bump?

I think the most common conclusion is: No, to be a breaking change in the semver sense, it needs to change the documented, intentional behavior.

Kyle

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CANk-BFpvn-ubdJLDhR_kRysQHd4YLTUUhtM6u9W4QtS8UvyfZA%40mail.gmail.com.

--

Kyle Cordes

http://kylecordes.com

[Keith Smiley]

As someone who builds exclusively on macOS I would prefer this change land ASAP so we don't introduce anymore silent violations of this.

[Laurent Le Brun]

To follow our policy strictly:

 - add a --incompatible_ flag in 1.2 (so submit it before Monday?)

 - flip the flag in 2.0, which will be in December (submit the flag flip in November)

If you want the new behavior to be present in 1.2, I'll let Dmitry decide.

If you don't have time to add the flag for 1.2, I'd personally vote for making the change in 2.0 anyway.

--

You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/1048d81c-fe7d-4087-9f34-4b8f7afdde5d%40googlegroups.com.

--

Laurent

[Tony Aiuto]

We have been a little broader than Kyle reasoning. "to be a breaking change in the semver sense, it needs to change the documented, intentional behavior." We have also included changes to undocumented, but widely used behavior.

The specifics for this are different either way.  You are fixing broken behavior to bring it back in line with documented behavior. It is clearly a bug fix. I could easily see anything related to failure to sandbox network calls as a security bug, so we would not only fix it without a long incompatible process, we would backport to LTS releases.

So, I'm with Laurent. We should do this by 2.0. The only question is if we fix it earlier or not.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CAFtxR%2BkZms063bo6AnWTnpyzoe7mJ%3DKJ0PZVxugvjF4s%3DgdoaA%40mail.gmail.com.

[Austin Schuh]

And to be clear, if the default behavior isn't what you want, you can
add --experimental_sandbox_default_allow_network=false to your
.bazelrc file

Austin

> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CACpMnus49yDGDLu6JQasptQEfUxd2L_vKhRQpAu2ACH1XFv-6g%40mail.gmail.com.

[Julio Merino]

On Thu, Oct 31, 2019 at 3:04 PM 'Tony Aiuto' via bazel-dev <baze...@googlegroups.com> wrote:

We have been a little broader than Kyle reasoning. "to be a breaking change in the semver sense, it needs to change the documented, intentional behavior." We have also included changes to undocumented, but widely used behavior.

The specifics for this are different either way.  You are fixing broken behavior to bring it back in line with documented behavior. It is clearly a bug fix.

Right... And the problem with delaying the fix is that things will get worse for people the longer the bug exists, as their builds can gain undesired networking dependencies that'll be cut later.

 

I could easily see anything related to failure to sandbox network calls as a security bug, so we would not only fix it without a long incompatible process, we would backport to LTS releases.

That's a dangerous line to cross. Sandboxing has never been a security feature in Bazel so far, and we should not imply it is. Doing so has deep implications, starting with the fact that we ought to harden it significantly.

So, I'm with Laurent. We should do this by 2.0. The only question is if we fix it earlier or not.

I don't understand... What Laurent is saying is that this change should be treated like other backwards-breaking changes. But what you say here seems to imply that this change is not subject to the incompatibility policy and I should just roll out a fix? Seems to be the two opposite possibilities...

--

jmmv.dev

[Tony Aiuto]

I thought his words were "do this by 2.0, even if there is no time to do a full incompatible flag thing". I am also arguing that it is not subject to the policy. Basically, I am coming up with "just do it now" from different angles.

 

--

jmmv.dev

[Julio Merino]

Ah, that works for me.

Won't have the change ready immediately, so I'm curious about what Dmitry might have to say when he's back to the office.

--

jmmv.dev