OFFICIAL_BUILD flag

[Ryan]

Hello,

Is there an official meaning/definition of the flag OFFICIAL_BUILD (is_official_build)?

What are the consequences of enabling or disabling this flag?

At first glance, it appears to control the amount of optimization when creating a build.

However, some features like static key pinning is also controlled by this flag.

https://cs.chromium.org/chromium/src/net/http/transport_security_state.cc?q=transportsecuritystate&sq=package:chromium&dr=CSs&l=724

Thanks,

Ryan

[Brett Wilson]

It's supposed to be optimization only.

Sometimes people get it confused with GOOGLE_CHROME_BUILD and we end up with some non-optimization-related things. I suspect the key pinning you point out is one of those cases.

Brett

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Elliott Sprehn]

If that's its purpose can we rename it something like LOTS_OF_OPTIMIZATIONS (clearly bikeshed)?

Ive been confused by this, and I know lots of other folks who have been too. :)

[Brett Wilson]

I think renaming it would be great, but we should keep the build flag (is_official_build) in sync to avoid extra confusion, and that will be somewhat involved to change due to bot config stuff.

Brett

[Marshall Greenblatt]

On Tue, Jul 26, 2016 at 12:43 PM, Brett Wilson <bre...@chromium.org> wrote:

It's supposed to be optimization only.

Sometimes people get it confused with GOOGLE_CHROME_BUILD and we end up with some non-optimization-related things. I suspect the key pinning you point out is one of those cases.

FYI I filed a bug for this a while back: http://crbug.com/574126

 

Brett

On Tue, Jul 26, 2016 at 9:34 AM, Ryan <ryan...@chromium.org> wrote:

Hello,

Is there an official meaning/definition of the flag OFFICIAL_BUILD (is_official_build)?

What are the consequences of enabling or disabling this flag?

At first glance, it appears to control the amount of optimization when creating a build.

However, some features like static key pinning is also controlled by this flag.

https://cs.chromium.org/chromium/src/net/http/transport_security_state.cc?q=transportsecuritystate&sq=package:chromium&dr=CSs&l=724

Thanks,

Ryan

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

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

[Dirk Pranke]

This is one of those things that'll be easier to clean up once we drop GYP support, and it makes sense to do that then (there's some

other work that also needs to happen to clean up the way we control optimization levels and settings).

-- Dirk

[Peter Kasting]

On Tue, Jul 26, 2016 at 11:00 AM, Dirk Pranke <dpr...@chromium.org> wrote:

This is one of those things that'll be easier to clean up once we drop GYP support, and it makes sense to do that then (there's some

other work that also needs to happen to clean up the way we control optimization levels and settings).

For clarity, I think Marshall's bug about incorrect use of OFFICIAL_BUILD where GOOGLE_CHROME_BUILD was intended can and should be fixed immediately.  The proposal to rename OFFICIAL_BUILD is what probably should wait until GYP is dropped.

PK 

[Dirk Pranke]

That's exactly what I meant; thanks for clarifying.

-- Dirk

[Primiano Tucci]

For extra clarity, another major difference between is_official_build (OFFICIAL_BUILD) and is_chrome_branded ( GOOGLE_CHROME_BUILD) is that you should be able to do an official build from a full upstream checkout and that should have the same performance characteristics of what we ship.

Instead you need an internal checkout to do a chrome-branded build.

Everything that diverges from this should be a bug (official build depending on internal data or performance tuning that depends on branding).

upstream official-buildability has quite some large coverage as all the upstream perf builders use is_official_build. Instead nothing can prevent people to have optimizations conditioned by is_chrome_branded. If you see that file a bug.

--

[Bill Budge]

I'd like to revive this thread to propose that we keep 'is_official_build' and the "OFFICIAL_BUILD" concept.

From browsing Chromium source code, it seems this flag means more than just "optimized". There are several places where we loosen security for developer convenience.  In windows sandbox code, we allow read-only access to .PDB files for stack traces:

https://cs.chromium.org/chromium/src/content/common/sandbox_win.cc?type=cs&q=official_build&sq=package:chromium&l=360

Similarly for POSIX stack traces:

https://cs.chromium.org/chromium/src/base/debug/stack_trace_posix.cc?type=cs&q=official_build&sq=package:chromium&l=622

And:

https://cs.chromium.org/chromium/src/content/app/content_main_runner.cc?type=cs&q=official_build&sq=package:chromium&l=639

I'd argue that 'is_official_build = false' means the build is intended to be developer-friendly and not shipped to end users, and 'is_official_build = true' means that any developer-friendly features that weaken security are disabled.

Here's a CL to make this meaning clearer:

https://chromium-review.googlesource.com/c/chromium/src/+/714443

[Dirk Pranke]

I'm not wild about overloading is_official_build to have security implications, particularly since it hasn't historically had that meaning.

I would be fine with an `is_developer_friendly_but_insecure = !is_official_build` arg and a separate define.

I could be convinced that it's okay to change the meaning of OFFICIAL_BUILD (I don't necessarily like creating more flags), what I wrote above is just my knee-jerk reaction.

-- Dirk

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/986081c9-9b95-4ee7-9059-fd98af178578%40chromium.org.

[Daniel Cheng]

Do other Chromium embedders ship binaries with OFFICIAL_BUILD=1? If they don't, I guess that would be a reason not to use that flag to guard it.

I guess we could use a new GN arg too and default it to disabled...

Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTCDjzX_P5%2B469t49vG8Lc09j-a6H9yUNcA%3DL9ay-TczuQ%40mail.gmail.com.

[Yngve N. Pettersen]

On Thu, 12 Oct 2017 02:18:44 +0200, Daniel Cheng <dch...@chromium.org>
wrote:

> Do other Chromium embedders ship binaries with OFFICIAL_BUILD=1? If they
> don't, I guess that would be a reason not to use that flag to guard it.

FYI, The public binaries of the Vivaldi browser are built with
is_official_build=true, and we have code using the OFFICIAL_BUILD to
enable/disable particular code and features.

>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/986081c9-9b95-4ee7-9059-fd98af178578%40chromium.org?utm_medium=email&utm_source=footer>
>>> .

>>>
>>
>> --
>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-dev
>> ---
>> You received this message because you are subscribed to the Google
>> Groups
>> "Chromium-dev" group.
>> To view this discussion on the web visit

>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTCDjzX_P5%2B469t49vG8Lc09j-a6H9yUNcA%3DL9ay-TczuQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTCDjzX_P5%2B469t49vG8Lc09j-a6H9yUNcA%3DL9ay-TczuQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>


--
Sincerely,
Yngve N. Pettersen
Vivaldi Technologies AS
Phone: +47 40 40 14 82

[Yan Zhu]

On Thu, Oct 12, 2017 at 12:33 AM, Yngve N. Pettersen <yn...@vivaldi.com> wrote:
> On Thu, 12 Oct 2017 02:18:44 +0200, Daniel Cheng <dch...@chromium.org>
> wrote:
>
>> Do other Chromium embedders ship binaries with OFFICIAL_BUILD=1? If they
>> don't, I guess that would be a reason not to use that flag to guard it.
>
>
> FYI, The public binaries of the Vivaldi browser are built with
> is_official_build=true, and we have code using the OFFICIAL_BUILD to
> enable/disable particular code and features.

Brave also uses is_official_build=true

embedder-dev might be a good place to ask this

> ---You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev...@chromium.org.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/op.y7yzt5wqpvqxoc%40killashandra.router.invalid.
>

[Marshall Greenblatt]

On Oct 12, 2017, at 3:18 AM, Daniel Cheng <dch...@chromium.org> wrote:

Do other Chromium embedders ship binaries with OFFICIAL_BUILD=1? If they don't, I guess that would be a reason not to use that flag to guard it.

CEF uses is_official_build=true for shared libraries. However, we ship the sandbox code + dependencies as a static library on Windows because the sandbox code must be statically linked in the client executable. We currently build the sandbox library with is_official_build=false  for smaller size and to avoid /LTCG warnings [1]. Sounds like we'll need to make some adjustment given the sandbox security considerations mentioned above.

[1] https://bitbucket.org/chromiumembedded/cef/issues/2220

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAF3XrKpikJHYsmqiA%3DHjNT7CSN8HExcPDAh%3D3J9_khCQN39JFw%40mail.gmail.com.

[Bill Budge]

I thought about adding something like that - say "is_unsafe_developer_build". However, if we set it to !is_official_build, it seems like we have the same problem when developers don't have is_official_build = true. Am I missing something?

Otherwise, the new flag seems like a pain for developers to change locally and on relevant bots. I'm guessing we'd need a bunch of changes to bot recipes. Is that true?

Also, it seems like we're facing a refactoring project to put all existing unsafe code gated by OFFICIAL_BUILD behind the other flag UNSAFE_DEVELOPER_BUILD. However, it's an attractive idea, as it eliminates the hazard and seems like a good thing for helping developers too, as we can add other features (e.g. predictable ASLR for debugging) without the fear they're unknowingly being deployed to users.

[Dirk Pranke]

On Thu, Oct 12, 2017 at 12:19 PM, 'Bill Budge' via Chromium-dev <chromi...@chromium.org> wrote:

I thought about adding something like that - say "is_unsafe_developer_build". However, if we set it to !is_official_build, it seems like we have the same problem when developers don't have is_official_build = true. Am I missing something?

I think one of us is missing something, but it might be me :).

If the general idea is that the flags are disabled for developers and enabled for official builds, then

declare_args () {

  use_unsafe_developer_features = !is_official_build

}

configs("unsafe_developer_features") = {

  if (use_unsafe_developer_features) {

    defines = [ "UNSAFE_DEVELOPER_BUILD" ]

  }

}

seems like the way to go. You wouldn't need to change any bot configs, and I think having a separate define makes the code intent a lot clearer.

The only time a developer would need to change something locally is if they are doing an official build but wanted to enable the unsafe features, and that seems like the situation where they *should* have to do extra work, because they're doing something we don't normally want them to do, right?

-- Dirk 

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/13221d94-e84c-4a34-85fb-92abb28a2fa6%40chromium.org.

[Joe Mason]

(Resending from my chromium account.)

Use of OFFICIAL_BUILD in the sandbox code worries me. The Sandbox is meant to be usable for applications outside chromium (at least according to the faq at https://chromium.googlesource.com/chromium/src/+/lkcr/docs/design/sandbox_faq.md#This-is-very-neat_Can-I-use-the-sandbox-in-my-own-programs) and it's not at all obvious that some security features are turned off if you don't enable that define while building it.

If we can't get rid of these uses completely, +1 to a "developer_friendly_but_insecure" flag, so that if an embedder fails to enable the define they get the more secure behaviour. Adding this and basing it on the inverse of OFFICIAL_BUILD won't make a  difference for building all of chromium, but it's a win for people who pull out smaller pieces for other projects (eg. the sandbox, or mojo).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/13221d94-e84c-4a34-85fb-92abb28a2fa6%40chromium.org.

[Joe Mason]

Just realized I was misreading the sandbox example - that code is in content/.../sandbox_win.cc, which is Chromium setting options for the sandbox, not sandbox/win/... which is the implementation of the sandbox that other projects might want to use outside Chromium.