|
Denis,
Comments below.
On 27.08.2019 20:47, Denis Roy wrote:
Ed,
Would you feel better setting aside your winter instead of
summer?
Well, I'd prefer the fall if given a choice.
We operate an open/transparent organization. Your shell-based
mission-critical tasks are trapped inside your shell.
Yes, that's why I've been migrating them. I agree they're better as
jobs, but some of us are old, and we're used to doing things other
ways. We're just not the new cool kids. In the old days, shell
access wasn't insane.
Putting them in a CI would do everyone a world of good, so
that others can contribute to your enjoyment of summer.
Of course I practically live for the good of others. :-P
I do agree that you are ill-informed. What we're doing here is
not ultra-security, as you refer to it. What we are doing is on
page 2 of the "Running a server on the Internets 101" book that
was published in 1992.
You're not throwing dogma in my face are you!?
And you're right - Jenkins vs. shell is not much better. The
new Jiro (on Kubernetes) is.
It's hard to keep up with the de jour trends. They change almost as
quickly as one changes one's underwear. Will what I do on Jenkins,
which worked fine in a shell, but is insane there, stop working on
Jiro when its been Kubernetized into the latest jargon-laden trend
technology? Or is there a migration path involved?
Matt has been doing some digging and I believe has some
potential workarounds for yourself, and Markus. Stay tuned.
I'd probably be done with my migration if the infrastructure
would just cooperate. But then what would I complain about?
This just annoys the living heck out of me though:
[INFO] Unpacking org.bouncycastle.bcprov_1.61.0.v20190602-1335...
[ERROR] The following artifacts could not be downloaded:
[ERROR] osgi.bundle,org.bouncycastle.bcprov,1.61.0.v20190602-1335
[ERROR] Internal error: java.lang.RuntimeException: Some required artifacts could not be downloaded. See log output for details. -> [Help 1]
Why did that start at 3:00PM today, just as I try to get the p2
indexer working? It's not that it couldn't resolve the thing, it
can't download it, even though it's resolved. Why?! Why now when
I need builds to work, when I need to get M3 working in the tiny
gap between Mac-can't-sign and Tycho-can't-download-file.
Thanks for understanding,
As I said, sorry for ragging on you. I know it's hard to balance
all these things. But I'm just annoyed and very frustrated. I'm
sure many will not appreciate how much gets done in the background
until it's no longer done at all.
Denis
On 2019-08-27 2:26 p.m., Ed Merks
wrote:
Denis,
Comments below.
On 27.08.2019 19:27, Denis Roy
wrote:
Ed,
I think we're one of the last shops on earth that has SSH
shell access right into our mission-critical infra.
Being able to use vi in my home folder doesn't strike me as
treading into your mission-critical infrastructure, but hey,
I'm clearly not well-informed. I must point out though that
like Markus, I provide numerous services that are also mission
critical. But, for the greater good of ultra-security, of
course I'll quickly set aside my summer and my personal life
to address, at my own expense, this latest pressing security
concern inorder to find alternative ways to make things work
nevertheless.
But wait, I couldn't do a build for days because Mac signing
didn't work. Oh, and suddenly today, out of nowhere:
[ERROR] The following artifacts could not be downloaded:
[ERROR] osgi.bundle,org.bouncycastle.bcprov,1.61.0.v20190602-1335
[ERROR] Internal error: java.lang.RuntimeException: Some required artifacts could not be downloaded. See log output for details. -> [Help 1]
My builds fail again for another reason. In the end though, ulta-security waits for no person.
Even before 2009 this practice was pure insanity from a
data/systems security perspective but it was maintained as
there were not many options.
Really? File access permissions are so insanely insecure? So
if I login and delete a file, that's just insane, but when I
run my Jenkins job to delete that file, it's totally secure
and the world is safe. I totally don't get it, but as I said,
I'm ill-informed.
With Jenkins per Project (JIPP), there's just no reason to
leave a well-known security faux-pas enabled. It's like
putting a credit card number on LinkedIn.
As I assumed, it's all for the greater good. Much like that
"It's so reassuring that so many people will benefit from that
new highway that will consume your home and property." On that
front, I know I always feel so much more secure when I have to
agree to yet another cookie prompt on a web page. Thanks EU,
I feel like my web experience is totally ultra-cookike-secure
now. I just need that highly in-demand
the-make-the-cookie-go-away app. And whenever I do anything
around here where I live now, I have to sign the data security
form, that I can't read, but must sign nevertheless. It
totally makes me feel like my best interests (security) are
always the prime concern.
As I understand it, there were less than 30 people with
full shell access. If hundreds of projects don't need it,
it's really hard to justify.
Of course we were given ample opportunity for justification. And
of course trying to justify insanity would just be proof of
insanity. So good for us that there are those who decree that
plain insanity is something to which we must put and end,
immediately, during the summer, when of course no one has
anything better to do than migrate to the new improved
ultra-secure non-insane better alternatives: run Jenkins jobs
for hours trying to do accomplish what you could do in minutes
with a shell.
In the end, we're not here to intentionally piss folks off
with useless dogma -- we're here to help. Part of that
mission statement is making sure our systems don't suffer a
catastrophic compromise/data breach.
It's feels so much better to be pissed of unintentionally.
:-P
Of course your role is to serve the best interests of the
community, and I feel bad to rag on you because I do feel you
are doing your best to serve the interests of the community.
But it also feels like dogma to me, much like the
cookie-phobic, ultra-data security madness that plagues me at
home.
Perhaps if we better understand what you use the shell for,
we can help craft CI jobs which will both a) accomplish the
task and b) provide everyone with more visibility into
what's going on, as opposed to some cryptic cron job. Feel
free to file bugs in Community / Jenkins for the tasks you
need assistance with.
Feel free to open problem reports that we can promptly do
nothing about. No, expect nothing and you will not be
disappointed. I will try to make due without.
Denis
On 2019-08-27 12:46 p.m., Ed
Merks wrote:
Matt,
So in the end, a restricted shell is essentially so
crippled as to be effectively useless, and there exists no
actual concrete "definition" of what, if anything, useful
might in reality be accomplished with a restricted shell.
I should point out that this is quite different from the
impression that was presented earlier in this process, so
I'm disappointed in how this has been presented and
handled. It feels to me like a process of decree where
there is no recourse:
"We've come to claim your property to build a new
highway; we're very sorry that you'll have to move out
before the end of October, but it is for the greater
good."
Regards,
Ed
On 27.08.2019 16:44, Matthew
Ward wrote:
Hi Ed,
The restricted shell was originally created with
the goal of providing committers a way to interact
with the downloads/archive filesystems for releng
activities, and version control systems without
providing a general purpose shell. So naturally the
command set available leans in that
direction(mv,cp,mkdir,git etc).
We are certainly willing to discuss adding extra
commands either temporarily or permanently, but I want
to make it clear that the goal is not to reproduce
bash.
-Matt.
What will we be able to do in restricted shell?
Using vi is a very basic activity. I suppose
there must be some good reason why that's
restricted? Earlier I was under the impression
that such simple things would continue to work,
but now I have to wonder. But then it was
mentioned that things we discover needed could
become unrestricted...
On
26.08.2019 15:35, Matthew Ward wrote:
Hi David,
Thanks for the questions.
Users with the restricted shell will have
the same home directories that they do
currently, which will remain the place for
authorized keys. You won't be able to
edit(vi/emacs/ed) files directly within the
restricted shell, so you will need to upload
them via scp/rsync. If you want a more
'interactive' type of access I'd suggest
looking into using libfuse, and specifically
the sshfs file system.
The restricted shell allows rsync, so there
should be zero impact. If you'd like to test in
advance, drop me a line and I'll set you up.
-Matt.
On
8/23/19 14:24, Matthew Ward wrote:
Hi Everyone,
I just wanted to follow up with a
reminder that on August 28th we will
be moving committers that have an
actual shell on Eclipse.org to our
restricted shell.
I'd like to thank both Donat and
Etienne on the Buildship RelEng team
who volunteered to test this change,
and helped me confirm that this change
should be minimally disruptive.
If you have any questions, please
let me know.
-Matt.
Thanks for the reminder.
Will those of use that still want to use
'scp' and similar still have a 'home
directory' (on "build"?) and is that still
the place for .ssh/authorized_keys2? Or,
does all that change with "restricted
shell"?
If a change, can you point me to
instructions on how to set that up? I would
assume some form of "ssh-copy-id hostname"
but thought best not to assume and ask
explicitly.
In case you are wondering, the use case, for
using scp and similar is to download a
number of builds to my local machine
(without going through web interfaces).
Now that I think of it, I currently use
rsync via ssh, such as
rsync -a -e ssh ${ committer_id}@build.eclipse.org:${dlpath}
"${output_dir}"
Will that still work with a restricted
shell? Or, will I need to convert to "scp"?
Thanks,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
