rename developer mode?

[Trever]

Has there ever been any thought about renaming developer mode to something else?

1.  The name conflicts with the developer channel (causing endless confusion for some)

2.  With the ability now to re-enable verified boot in developer mode, other use cases for the ____ mode become even more compelling for the Chrome OS platform.

This comes to my mind:

Linux mode

I realize this may be an unpopular discussion, but.  Seems like a question that needs to get asked.  Searched and didn't find any previous discussions...

Trever

[Richard Barnette]

On Mar 2, 2013, at 11:41 PM, Trever <trr...@gmail.com> wrote:

> Has there ever been any thought about renaming developer mode to something else?
>
> 1. The name conflicts with the developer channel (causing endless confusion for some)
>
> 2. With the ability now to re-enable verified boot in developer mode, other use cases for the ____ mode become even more compelling for the Chrome OS platform.
>

Yes, the term "dev" is heavily overloaded, since it can refer to
1. The "dev channel"; a sequence of releases meant for
early adopters to try out new features,
2. A "dev image", meaning a build with certain developer
features enabled that aren't present in production images, and
3. "dev mode", a mode of Chrome OS hardware that relaxes
certain boot time security checks.

> This comes to my mind:
> Linux mode
>

As far as descriptive alternative names go, the best I know of
would be "unverified mode" or "unverified boot mode".
These accurately describe the behavior of the firmware when
the mode is enabled. There's also some precedent, since
some of the documentation regarding recovery (plus messages
in the firmware and in recovery) use this kind of terminolgy.

> I realize this may be an unpopular discussion, but. Seems like a question that needs to get asked. Searched and didn't find any previous discussions...
>

Yeah, although there's a case to be made, and some documents
with better terms, there's a snowball's chance in hell that anyone
will go and update all the relevant documents, let alone persuade
all the developers to change the language they use to talk about
these concepts.


>
> Trever
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
>
>

-- jrb

[Trever]

Thanks Richard.

Yes, I understand about the snowball (obviously).

Regarding the "case to be made":  the thing is, it is at least possible that in the future, most people who run anything that quacks like UNIX for a "desktop" (very broadly defined) will be doing this on a Chrome OS device.  I'm not saying they will be using Google's entire ecosystem, but they may very well be using a Chrome OS device and (importantly) a Chrome OS device that is booting KERN-A/B and ROOT-A/B, probably verified too.

Feel free to hoot and holler and roll your eyes all you want, the possibility of this being so remote it's not worth responding to kind of thing.  Where does one start with a statement like that?  Don't even bother, right?

My prediction is that this will happen.  I won't make the case here.  

I do think this is a "different argument" for the name change?  I certainly understand this "market" possibility is not what Chrome OS devices are for, and that the mother ship isn't interested in the sales numbers for that scenario.  And it falls on the other side of the bright line testing for the devices, support, blah blah blah.

Ducking incoming rotten vegetables, and pointing out that I'm rubber, you're glue, everything you say bounces off me and sticks to you- I stand by my prediction- I do believe Chrome OS as the majority of casual and many work-a-day "UNIX" workstations is a more likely outcome than not.  It would also be a weird argument for the producers of Chrome OS devices to insist and want my prediction to never come true, but that's another story.

The point is, it'll go better if the Linux mode (both verified and unverified) is renamed now.  That's the point.  

It won't make any sense when people are using Chrome OS devices as Chrome OS + additional userland Linux machines and they are all running around in "developer" mode on these machines.  Because these people are not all developers by a long shot, and certainly not Chrome/Chromium OS developers.  It just isn't the right name, to say nothing of the overloading.  And I don't think "unverified mode" nor "Linux mode" are good names.

Okay, I think I will leave it at this.

Most people (full time developers especially) thought I was daft when I said XML will never take over the world for data exchange only because it will drive *people* (not machines) crazy, and no doubt they'll think I'm daft now.  I can feel the heat that poor snowball is experiencing...

:-)

Trever

[Trever]

It could be called Goobuntu mode.

[Trever]

gentoogoobuntu mode?

(Say it five times fast!)

If I were Google, why would I push out a stripped down Linux distro to the masses and not use it internally, adding things as needed with dev_install (say)?  Why would I not do that, *and* pay to develop my own Linux distro based off something else (i.e. Goobuntu)?

I am near certain that there are answers to such questions and that a name change- compared to everything else going on there- is a necessarily low priority.  

I don't have those issues though, so the name change is more compelling.  :-)

Okay, thanks for listening, I will stop with this issue.

Trever

[Steve Pirk]

I have always referred to it as dev mode, but Richard's comments reminded me what it is, a developer mode that turns off boot verification. From this point forward, I will quit shortening the name and refer to it as developer mode (instead of dev mode). The word developer (a person) is not easily mistaken for development (a thing), so it might help a little :)

-- steve

[Trever]

Well, strictly speaking, you're making my case (seems to me).

It doesn't turn off verification.

It does, but you can turn it back on and it stays on until you turn it off or leave dev mode altogether.

For this and other reasons, the mode has some compelling use cases, and is therefore not well named.  

Trever

[Trever]

Forgot:  I should also point out that Bill Richardson has said that originally, when dev_boot_signed_only was created, it was by default set to 1.

Meaning:  enable dev mode, and verification is ON.  You then had to go the extra step to turn it off from the command line.

But, that had to be reverted.  It broke factory building.  So it's the way it is now. 

[Steve Pirk]

Damn good point Trever. When I boot my Cr-48 when it is in dev mode, it  tells me os verification is turned off, but if I just hit ctrl-d within 30 seconds, it boots fine. The os is still signed, and the device updates like a real Chromebook, but I have bash shell and root access.

It is 10 minutes to two in the am here, so take this with a grain of salt. When you do this, you are not really breaking anything, you are essentially rooting your device. How about we call it "superuser mode", or just "enabling superuser" on your Chrome OS device?

-- steve

[Mike Frysinger]

if you see that screen & hit ctrl+d, then the signing of the kernel &
rootfs doesn't matter. it'll boot any code that has a valid signature
block.
-mike

[Steve Pirk]

Thanks Mike,

Again, another good point. As long as i do not mess with the code the Chromium team sends me with each update, I can feel relatively safe in knowing that my Chromebook is still secure. If I somehow let some app or malicious entity mess with the the os image, then shame on me :) 

Superuser, but with no guarantees that my OS is secure. It is up to me to make sure that that is the case. It is the price you pay for having superuser or sudo access to the machine. Caveat emptor, let the buyer beware :)

-- steve

[Randall Spangler]

As the author of the original verified boot document, I apologize for the confusion.

What we originally though of as "a mode for developers to run their own code on the device" has evolved into a range of use cases:

• I just want a root shell, please (but still verify everything on boot)
• I just want to run ubuntu in a chroot (so I can play Minecraft)
• I want to run some other prepackaged distro
• I want to dual-boot to some other OS (maybe even Windows) (maybe from USB/SD)
• I want to build and run my own Chromium OS
• etc

In some of these cases you'd like Chrome OS to stay as verified as possible when you're running it.  In some cases it'd be handy if you could tell the firmware what key you expect your OS to be signed with, and have it use that key to verify your kernel.  In a lot of those cases you'd like to be able to switch back and forth between fully-verified Google Chrome OS and (some other OS) without enduring the delay and stateful partition wipe each direction.

So developer mode isn't even really a single "mode" anymore - it's a range of modes depending on what additional flags you have set.  The only common features are the scary boot screen (and we need that to ensure that users are making a conscious decision to run with reduced security) - and that once you've moved into what we now think of as "dev mode" you just need root (and not user presence) to change the additional flags.

So the clearest name is "not-fully-verified-and-secure-please-be-careful" mode, but that's a mouthful.

Hmm.  Perhaps we should have called this "unlocked" mode?  It's got the right connotations.

Renaming it now won't be much fun, though; there are hundreds of references to "dev" mode.  Maybe it fits into the rewrite of verified boot code that Bill and I are planning.

- Randall

[Bill Richardson]

A: Because it fouls the order in which people normally read text.

Q: Why is top-posting such a bad thing?

A: Top-posting.

Q: What is the most annoying thing in e-mail?

Trying to read this now... 

--

Art for Art's Sake

Engineering for Money

[Bill Richardson]

Okay, my $0.02:

We called it developer mode before we had any channels. We should change the developer channel to "alpha" or "unstable". Problem solved.

[Trever]

On Monday, March 4, 2013 11:05:10 AM UTC-8, Randall Spangler wrote:

As the author of the original verified boot document, I apologize for the confusion.

What we originally though of as "a mode for developers to run their own code on the device" has evolved into a range of use cases:

Thanks Randal (trying to remember not to top post...).

The evolution of the mode is clear enough, I'd imagine you don't need to apologize for the original name!  I'm not suggesting that it was originally badly named, btw.  The name makes sense, from various perspectives, and I'm sure when it was first conjured made perfectly fine sense.  Apparently you were there first (re what Bill says about the channels coming after).

A question that I hope will not seem to assume things it does not, or otherwise confuse:

Are those of us who are interested in some of the various use cases that involve developer mode- are we a pain?  If you could, would you discourage the questions and probing about dev mode?

It becomes a support issue in various ways.  It's also way off target of what Chrome OS devices (the things that have this mode) are really for.

Does this question make sense?  I think it is also appropriate for this thread.

You guys go somewhat out of your way to keep things open, hackable, useable in different ways, etc..  Everyone who has enough of a clue knows that.  So I don't want to be misunderstood.

Thing is I really *do* think Chrome OS (especially in dev mode with verified boot turned back on) has some nice use cases for UNIX users.  In many ways it's the desktop machine I've always wanted.  Stumpy is no slouch and Works For Me.  Now there's the Pixel....

For UNIX people, Chrome OS becomes kind of like Mac OS X, only better.

So the name of dev mode, what the vboot screen says, how long the firmware makes you wait in dev mode, whether and how you have to intervene, how much I can add with dev_install (out-of-the-box additions, as it were), etc. becomes more of an issue as these different use cases emerge.  

Is that a pain, on balance?  What would you say about all of this attention?

Thanks

P.S.  I'd *LOVE* to see a dev mode verified boot that somehow warns but goes fast too.  I think someone suggested a hardware light?  Not going to try to input into your redesign here, but you might consider soliciting ideas from the community as part of your vb redesign process, with the caveat that you reserve the right to ignore it all.  But many heads can lead to some ideas that might not otherwise have happened?

[Hung-Te Lin]

On Tue, Mar 5, 2013 at 3:14 AM, Bill Richardson <wfri...@chromium.org> wrote:

Okay, my $0.02:

We called it developer mode before we had any channels. We should change the developer channel to "alpha" or "unstable". Problem solved.

My vote for Bill's idea.

I've been asked many times for:

    "Is dev-channel signed with dev key?"

    "Why do I need MP-signed recovery if I use developer channel?"

    "Why am I not in developer mode / using developer key since I've already switched to developer channel?"

It would be nice if we can leave "dev" for "developer mode" stuff :)

(Well, even better if we can rename "developer key" to "testing key" or something else)

[Trever]

On Monday, March 4, 2013 8:33:30 PM UTC-8, Hung-Te Lin wrote:

    "Why do I need MP-signed recovery if I use developer channel?"

MP-signed...   Manufacturing Partner- signed?

What's MP stand for? 

[Hung-Te Lin]

    "Mass Production" I believe.

    "cat /etc/lsb-release" and look for RELEASE_BOARD which contains key name (ex, signed-mp-v3keys).

[Trever]

Okay thanks.

BTW, I can't find this info anywhere (hidden in plain view somewhere?), and if I'm supposed to deduce the answer to my question, I have failed.  Can you either point me where to look for explanation, or can someone provide an explanation?

Version 25.0.1364.126

Platform 3428.193.0 (Official Build) stable-channel stumpy

Firmware Google_Stumpy.2.102.0

What do the different fields represent?  

Eg. Chrome browser version is usually X.Y.Z, but today I see it's four fields, W.X.Y.Z

The Linux portion (Chrome OS) has today three fields:  3428.193.0

Is there meaning to the fields?

It's clear that the 25 in Version 25.0.1364.126 is often in some direct way related to M25 or I think I've seen called Release 25? 

This makes me feel clueless....

[Trever]

Well I did find this:

http://www.chromium.org/releases/version-numbers

[Steve Pirk]

So, on the platform it is a a branch of a the Linux kernel build (like 3.7.x.x), and the rest is the build number since they snagged the branch.

Yes, the major number in the version refers to a "version of chrome". As mentioned, the dev channel receives weekly builds.

It makes sense now that I have seen it described.

--

[Trever]

On Monday, March 4, 2013 11:05:10 AM UTC-8, Randall Spangler wrote:

In some cases it'd be handy if you could tell the firmware what key you expect your OS to be signed with, and have it use that key to verify your kernel.

This would be very cool if users can add in their own public key and thus sign their own OS's.

With a permanent (protected) option to use Chrome OS from the factory...

Very nice.

[Bill Richardson]

On Mon, Mar 4, 2013 at 11:50 PM, Trever <trr...@gmail.com> wrote:

Version 25.0.1364.126

Platform 3428.193.0 (Official Build) stable-channel stumpy

Firmware Google_Stumpy.2.102.0

What do the different fields represent?  

Beats me.

 

Eg. Chrome browser version is usually X.Y.Z, but today I see it's four fields, W.X.Y.Z

The Linux portion (Chrome OS) has today three fields:  3428.193.0

Is there meaning to the fields?

Probably, but it varies. 

 

It's clear that the 25 in Version 25.0.1364.126 is often in some direct way related to M25 or I think I've seen called Release 25? 

Yes. The major version is the important number for most people. Version 25, Milestone 25, and Release 25 are more-or-less the same thing, with minor differences involving what's tracked in the bug system, what's being tested, and what's released officially.  The other fields are probably things like bug fix update, branch point, build within branch, etc. and are used mostly by the release team to manage their processes. I saw some email about it a long time ago, but I've forgotten the details.

For me, I don't know what the numbers mean, but I know how to use them to reproduce the specific source code tree that produces a particular image. The Chrome browser is typically built separately from Chrome OS, and the firmware is built separately from either of those, and that's true for every platform. There are literally hundreds of separate git repositories used to build the Chrome OS image, and reproducing each of those three components requires checking out a distinctly different snapshot in each repo. We have an internal database of how to map the release numbers to those snapshots.

This makes me feel clueless....

It shouldn't. I don't know of anyone on the Chrome OS team who knows all the details about everything. There's too much and it changes too quickly.

Bill

[Bill Richardson]

On Wed, Mar 6, 2013 at 4:16 PM, Trever <trr...@gmail.com> wrote:

This would be very cool if users can add in their own public key and thus sign their own OS's.

We've done some experiments, but don't hold your breath. I intend to follow up on it and would like to eventually get it in, but changes to the verified boot process require firmware updates and we really don't like pushing those.  We make most of our vboot improvements only by releasing new hardware, and even then scheduling issues and security concerns can delay major changes.

[Trever]

On Thursday, March 7, 2013 9:03:44 AM UTC-8, Bill Richardson wrote:

On Mon, Mar 4, 2013 at 11:50 PM, Trever <trr...@gmail.com> wrote:

Version 25.0.1364.126

Platform 3428.193.0 (Official Build) stable-channel stumpy

Firmware Google_Stumpy.2.102.0

What do the different fields represent?  

Beats me.

For me, I don't know what the numbers mean, but I know how to use them to reproduce the specific source code tree that produces a particular image. The Chrome browser is typically built separately from Chrome OS, and the firmware is built separately from either of those, and that's true for every platform. There are literally hundreds of separate git repositories used to build the Chrome OS image, and reproducing each of those three components requires checking out a distinctly different snapshot in each repo. We have an internal database of how to map the release numbers to those snapshots.

This makes me feel clueless....

It shouldn't. I don't know of anyone on the Chrome OS team who knows all the details about everything. There's too much and it changes too quickly.

Thanks Bill for that.

I ended up re-asking about versions because there was some silence here for a bit and mostly because the version question really belonged in another thread.  Mike had some things to say:

https://groups.google.com/a/chromium.org/d/msg/chromium-os-discuss/gbSjs_2hS2I/_rvfeALiAxEJ 

[Ron Olsberg]

Randall

• I want to dual-boot to some other OS (maybe even Windows) (maybe from USB/SD)

I like this bullet.  I am not that interested in booting WinBlows on a Chromebook but booting Puppy Linux from a write locked USB stick would be great.

If ChromeOS would allow a soft boot after the Owner (and ONLY the Owner ) successfully authenticated to the device, maybe a flag could be set to allow booting from a USB device. This flag should NOT persist after a shutdown/power cycle.  I would have no problem booting into ChromeOS before being allowed to boot from a USB port.  Then we could enjoy the great security the Chromebooks have (Play Netflix etc..) and still be able to boot another Linux distro from USB.  Maybe this opens up some big security hole???

Just a crazy idea!!

Regards, Ron