Le lun. 29 mars 2021 à 10:24, Jesper Udby <[email protected]> a écrit :
> @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. > I hear that but I fail to see how 3.x x > 6 solves that. In all cases you will go that way - or not upgrade which is not a topic for that thread - and since 3.x will be advertised as fixing a security issue it wil be required anyway to go that way, no? So, at the moment, I only see people as being forced to backport the fix and configuration in all their settings to be able to pass security validations/certifications/... and still use the 3.6 to respect their versioning constraint. Would doing a 3.6.4 without the default config but the fix (which means it can be enabled but does not break OOTB) and a 3.7 (or whatever) with the config added in *by default* would be saner for everyone? Sounds like a good compromise for everyone, no? > > 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] > >
