@Romain: no not really. I'd hate to be in that situation where an
"innocent" 3.6.3->3.6.4 upgrade failed and I'd had to go into more
details about why. I've been to one of these orgs where I was doing
architecture, data modelling, solution development and devops (as a
one-man army) where unexpected surprises were not welcome.
Brgds
Jesper Udby
On 29/03/2021 09.37, Romain Manni-Bucau wrote:
@Jesper: just to refine, it is just a matter of adding a custom
settings.xml for the build/on the CLI (or override it in maven depending
what the org wants) to enable back http so you still don't have to set SSL
on nexus. Does it change your answer since the first point becomes no more
fully accurate with that fact?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 29 mars 2021 à 09:23, Som Lima <[email protected]> a écrit :
Any way thanks for the cli API
On Mon, 29 Mar 2021, 08:18 Som Lima, <[email protected]> wrote:
When you put a url in a browser and hit enter.
IF the url has to travel to a server on the intranet then an algorithm
ensuring tight coupling will be executed.
IF the url has to travel on the internet to get to a server then a
completely different algorithm gets executed.
The WAN algorithm relies on CHECKSUM to ensure data integrity.
It is weak and prone to easy vulnerability. At the very minimum the user
needs to implement encryption (HTTPS).
The LAN algorithm is quite different,
there is far more network traffic between two parties to ensure strong
secure connection.
API developers and application developers do not have access to this
layer. It is transparent.
On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, <[email protected]>
wrote:
Hi,
I kind of agree intranet is as secure as the internet (ie a lot of
attacks
done last years were done on intranets). yes you are in a local vpc not
accessible from the outside but it is also where hackers try to enter
first
since then it is open bar for them.
That said it is very common to use http as a quick serving too -
thinking
to trainings and hacking sessions where a tomcat serves a local m2 for
example.
I guess this all lead to the fact we need to support HTTP anyway and
enable/document how to still use it in the coming version (and not
prevent
it in a hardcoded fashion).
In terms of security it would be left to the user to enable it
explicitly
-
defaults being secured, exactly as the 0-day vulnerability got fixed in
all
softwares.
Sounds more than relevant to me to enable that case while it is not the
default.
That said, having this kind of toggle pushes to 3.6.4 more than all
others
by design then, no?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
Le lun. 29 mars 2021 à 08:51, Som Lima <[email protected]> a
écrit
:
I thought we were talking about computer programming algorithms.
Social engineering is outside the scope of the discussion on the
subject
of the algorithm devised in the invisible ( to API developers),
network
layer implementation.
The scope of discussion is that the intranet is a tightly coupled
comm
system therefore secure by design.
Imagine a couple holding each other tightly so no intruder, (third
party)
can come in between and interfere.
Meanwhile the internet (loosely coupled) due to physical limitations
could
not be implemented using the same algorithm.
It was left to users to work out the security which can be done using
encryption (HTTPS) as one means of security. Other strategies are also
available. Only the CHECKSUM was supplied as means of data integrity
by
the
network Gods.
Anybody want to talk about intraprocess (tight coupling) and
Interprocess
(loose coupling) ?
On Sun, 28 Mar 2021, 15:39 Markus KARG, <[email protected]>
wrote:
Nonsense. It is common sense that most criminal acts are spawned
from
within the local network, due to social engineering.
-Markus
-----Ursprüngliche Nachricht-----
Von: Som Lima [mailto:[email protected]]
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or
other
BTW there should be an option to still use unsecure http as many
people
run http in their LANs.
I could be wrong but I think the intranet is a tightly coupled comm
system
therefore it is secure by design.
On Sun, 28 Mar 2021, 13:31 Markus KARG, <[email protected]>
wrote:
We should not do any tricks or unexpected behavior but just stick
with
SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW
there
should be an option to still use unsecure http as many people run
http
in
their LANs.
If it contains backwards-compatible features, it has to be 3.7.0.
If it breaks backwards-compatibility, it has to be 4.0.0.
In no case it can be 3.8.0.
If mvnw was proposed for 3.7 but is not here now, then we either
have
to
wait with 3.7.0, or we have to tell people that we move mvnw to
3.8
or
4.0.
I do not see a need for any discussion at all, as SemVer is pretty
clear
about the sole correct answer.
-Markus
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:[email protected]]
Gesendet: Sonntag, 28. März 2021 11:47
An: Maven Developers List
Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or
other
Hi all,
Before we reroll the failed 3.8.0 I'd like we discuss openly the
next
versioning since it seems we didn't reach a consensus yet and
trying to
not
create too much friction for users and in the community.
As a reminder the only feature the release will get is to prevent
HTTP
repo
(in favor of HTTPS ones). In that regard it is a breaking change
if
users
rely on HTTP repo but a security fix (I don't come back on the
HTTP
->
HTTPS move IT ecosystem got recently here).
So it seems there are multiple versioning options:
1. 3.6.4: seems natural since it is a security fix, enables
companies
to
get this fix respecting a project versioning policy without having
to
upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon
4.x.
Indeed it requires a very well documented paragraph about this
change
and
how to workaround it (local proxy/mirror is a trivial one for
example)
but
it will be the case whatever version we pick anyway IMHO.
2. 3.7.0: since it is a breaking change it can seem natural too
(but
has
the pitfall to likely require a backport in 3.6 anyway, due to the
versioning policies which can prevent some users to upgrade to a
3.7)
3. 3.8.0: was the vote, seems the rational was that originally we
targetting mvnw in 3.7 and since we didn't make it 3.8 was used.
Have
to
admit I'm not sure of this reasoning more than that (cause for me
if we
don't have a planned feature we can either try to push/wait for it
or
postpone it but not skip a version due to that) so if anyone wants
to
complete the reasoning here it would be great.
Indeed my preference is for 3.6.4 which has the most advantages
for
everyone and no additional drawbacks compared to 3.7 or 3.8
options
until
we try to push to get mvnw in which would mean 3.7 becomes more
natural
(and likely imply a 3.6.x maintenance version).
Goal of this thread is to feel the overall trend and see if we can
refine
the proposals (for example: can we drop 3.8 one and only keep 3.7
and
3.6
or - best - can we refine it to a single version after some
exchanges).
If we keep a few proposals after some days, what about a vote
where
the
majority wins - we would just need to define how we count,
bindings/committers/all (my preference being last one indeed)?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
