[TriEmbed] GitHub heads up: password logins go away August 13th

Fri Jan 29 12:13:49 CST 2021

Thank you to *everyone* for taking the time to answer. I probably should
have been clearer. I have been using git since it was released both
professionally and personally and was one of the 2 "config meister's" on a
development team for a quite a while (but 5 years ago). Have experience
with several other version and configuration management tools as well (both
home grown at employers and commercial including some years managing my
teams' use of clearcase at 2 different companies)

Also the problem space as Pete pointed out is bigger than just one FRC
team.  Although The Forge Initiative membership has contacted with covid,
we still have multiple members of each of about 100 families engaged in
exploring tech - many of whom will eventually at least touch some software
development activity. This year we only have 12 FIRST teams in house
compared to the 25 we had last year. (1 FRC, 4 FTC, and the rest are
various leagues of FLL) if you've used ev3hub for FLL, it was developed by
one of our members Alan Smith.)

Our members' practiced core values mean that we are seldom concerned with
bad actors, but often want to be able to connect someone who made a mistake
with a peer or near peer who can help them understand what happened.

I see some useful to us suggested solutions for our approach and am really
grateful for them. (We have talked with other FRC teams - this is generally
not on their radar yet or they operate differently than we do - scale,
resources, intent, etc. There is room for lots of variation in FRC and FTC.
Also the FIRST Senior Mentor for NC is a member a is the head referee for
FTC in NC.  I think reaching out to FIRST at the national level makes sense
and will do that. Have been watching the forums for comments on this
problem for months.

*bitbucket* seems like a reasonable alternative. We do like all the code to
be visible to the whole world. In FRC that provides some competitive
advantages. We do want to restrict push access to team members, and
associate identity with each commit. Looks like we can do that with
bitbucket. I'll read more.

*Tokens* in the command line - this is really really close. On the FRC team
we commit and push from vscode. We use 2 plug-ins. A standard git plugin
that assumes your credentials are in the windows credential manager, or
that the identity is in git global or git local and then prompts for
password on push if needed. The second plugin is home brew and makes it
easy for a student to select their name and end up with their identity in
the local gut config for their repository. We might be able to enhance one
or the other to work with tokens. Again, our problem is seldom bad actors
and often "accessible to someone who already thinks it's very complicated".
It would be easy to simply ask every uaer to know their token. I'm not sure
how well it will work in practice.
*Still this is really good information.* We may be able to make use of.

*Setting up our own repo* - I'm glad to hear that it isn't anymore complex
that I thought it was. I don't think I'd set up a "server" so much as home
it in the cloud - Amazon or the like  It isn't my favorite solution. the
reasons are that the web access that we get from GitHub or would get from
bitbucket removes yet another obstacle to those who aren't quite sure they
want to code but might want to look at the code. That is always the
criteria - inviting the unsure to give to at least peek or try.

So once again thank you so much for the input all of the other suggestions
are interesting and useful but may not directly address what we need for
this problem.

Here's an interesting side note on developing what I think of as "extreme
volunteer engagement". We have lots and lots of volunteers who will spend
lots and lots of time on our organization's activities. The main reason for
that being so is because we emphasize finding tasks that each volunteer is
very excited to do. Often suggested by the volunteer themselves. This means
that we may not have a single volunteer interested in setting up how people
log into our systems. That sounds like drudge work you do at work to most
people who know how. However we have volunteers who will spend hours and
hours or even weeks writing a custom plugin because it's something no one
will let them do at work and they've  really want to do.

We're not very good at volun-told. We almost always make room for solutions
where someone "found a place in the community, connected and got to know
the team, asked how their idea would fit, prototyped the idea engaging
others and getting feedback along the way, especially if others can learn
by following along or contributing." Lol sounds complicated, but an amazing
number of people enjoy it and get amazing things done.

All of that changes the kinds of solutions that work for our organization.
Aspects of that may change as we grow and develop staff etc. But right now
that approach drives/shapes/cripples/biases/empowers our solutions. :-)

Rob

On Fri, Jan 29, 2021, 12:03 PM Jon Wolfe via TriEmbed <triembed at triembed.org>
wrote:

> On Windows, you can also configure git to use Window’s built-in credential
> management system so that you do not have to type in user/pass to do git
> operations. I think this mechanism will still work using tokens, but I have
> not tried it yet, despite GitHub already nagging me about it for the past
> few months. I’d bet money you can do that same thing on Linux/Mac, but on
> those platforms, I’ve used front ends for git that I think do that for me.
>
>
>
> I’m in the opposite boat, I’m a single individual with many git accounts
> in use on the same machine. I have to setup git so that uses “user/pass 1”
> for “repo A” and “user/pass 2” for “repo B”. Not only that, but some of my
> local repo’s have multiple remotes. This GitHub change is sure to be a PITA
> for me for years to come. I understand their rationale behind it, but when
> someone gets hacked, it’s going to be because they clicked on a phishing
> email and that the one thing that is still going to allow a username
> /password combination. One nice thing about user/pass authentication is
> that you can embed the user/pass into the url itself for https git
> operations. That’s not something you would want to do for a “production”
> workflow, for for one-off things with git, it saves a ton of hassle and
> setup for something you going to do one time.
>
>
>
> Setting up your own git central repo isn’t hard, the hardest part is
> getting the machine itself up and running to host it. I use software called
> “gitblit” that’s a java-based git server and website interface, that has
> low system requirements (beyond java), and works on Windows/Linux servers,
> and works on older machines too. It’s got a lot of GitHub/bitbucket – like
> features, and it very simple to install/setup.
>
>
>
>
>
>
>
>
>
> *From: *Pete Soper via TriEmbed <triembed at triembed.org>
> *Sent: *Friday, January 29, 2021 11:24 AM
> *To: *triembed at triembed.org
> *Subject: *Re: [TriEmbed] GitHub heads up: password logins go away August
> 13th
>
>
> Sorry to be a chatter box.
>
> With Bitbucket you just put your credentials into the local .git/config
> after defining the global git username and email address. I'm 98% sure
> if you set up ssh keys for a particular local PC you can bypass having
> to enter a password to do a push but I'm too lazy/stupid to do that. I
> just flirt with carpal tunnel and trust my fingers to type the password
> with close to zero effort.
>
> -Pete
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: TriEmbed at triembed.org
> List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
> To unsubscribe, click link and send a blank message: mailto:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: TriEmbed at triembed.org
> List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
> To unsubscribe, click link and send a blank message: mailto:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20210129/933337f9/attachment.htm>