> The main functionality of micronaut framework is REST, so this library is scanned for vulnerabilities regularly and fixes them asap (looking to [1] it takes about a week). I don't think that Ignite REST server implementation will be scanned as regular as micronaut and issues will be fixed as quickly as micronaut does.
The problem is not the scan frequency. The actual problem is the release cycle: somebody should fix a vulnerability in some dependency, then that dependency should be released and in the end Ignite should refresh dependencies and then should be released. In absence of dependencies we just fix the problem and build a maintenance release. > As for autogenerated spec, I would mention that manual spec writing introduces the second source of truth for the API. So, implementation declares one API, spec declares another API and there is no prooved contract between them. >From my point of view this is a bogus problem. Of course the described situation is possible and often happens. But the presence of a generation step does not protect against problems on other levels. I can describe the interface correctly but implementation of this interface can be wrong. So such instruments give just an illusion of correctness. Where is the truth? In fact, no one knows. On Fri, May 20, 2022 at 3:39 PM Aleksandr Pakhomov <apk...@gmail.com> wrote: > > Hi Andrey, > > Thank you for the valuable arguments. > > Speaking about micronaut, it is a popular library that > provides a lot of build-in features like error handling, > auth, IoC, test infrastructure, and many more. The main > functionality of micronaut framework is REST, so this > library is scanned for vulnerabilities regularly and fixes > them asap (looking to [1] it takes about a week). > I don't think that Ignite REST server implementation > will be scanned as regular as micronaut and issues > will be fixed as quickly as micronaut does. > > As for autogenerated spec, I would mention that manual > spec writing introduces the second source of truth for > the API. So, implementation declares one API, spec > declares another API and there is no prooved contract > between them. For example, a developer adds "name" > parameter to the existing endpoint and goes to the > spec and adds "names" parameter there (makes a mistake). > What is the right parameter here "name" or "names"? > Also, if there won't be a compatibility test this mistake could > go to the production and API spec consumers could get > a REST client that is not compatible with the server. > > > > On 19 May 2022, at 00:32, Andrey Gura <ag...@apache.org> wrote: > > > > I personally don't support any additional 3rd party dependencies as > > well as I don't fully understand the value of autogenerated specs for > > REST endpoints. In my opinion we have another option: writing spec > > manually. This option doesn't require any of proposed dependencies and > > allow to avoid possible vulnerabilities. Of course at the cost of > > manual actions. > > > > I understand that my statement is arguable. So I'll just wait for > > opinions of other community members. >
