[Geoserver-devel] making some great progress on mkdocs

[Jody Garnett]

As mentioned in a couple of meetings this summer GeoCat has been looking at
migrating documentation from reStructuredText to Markdown
(specifically Material
for MkDocs ).
Started in Bolsena the geonetwork transition is done  by a script
 which we can adapt for other
projects.

I promised to report back on how it went, and yeah it is going well. In due
course I will be making a proposal for GeoServer.

I have made a proposal for GeoTools here
https://github.com/geotools/geotools/wiki/MkDocs (to take advantage of the
30.x transition) for anyone wishing a sneak peak at what is involved.
--
Jody Garnett
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Carsten Klein]

Another idea:


Couldn't there be a more extensible way to declare a SPI provided
function "SQL encodable" for a certain Store (e.g. PostGIS)? Maybe
a tag interface "SqlEncodable" could do that job?

No, it does not make sense... a filter may be sql encodable in one 
database, but not in another, and a function is available
for the whole system. I doubt there are many functions that are sql 
encodable in all databases we support.


Why not using N tag interfaces, one per DataStore?

You could define tag interface 
org.geotools.data.postgis.PostgisSQLEncodable in plugin jdbc-postgres. 
This type could unconditionally be added to FilterCapabilities in 
createFilterCapabilities in class FilterToSqlHelper:


caps.addType(PostgisSQLEncodable.class);

Implementors of plugin-defined filter functions could then implement the 
tag interface(s) that corresponds to the desired DataStore(s) (if 
available). Of course, that mechanism is not ideal for built-in 
functions, which aim to be generally available (aka work with 
DataStores). But, this is likely much simpler than implementing another 
SPI...


You can repeat the above steps e. g. for jdbc-oracle, jdbc-mysql, etc. 
But that's not a MUST - such a tag interface is not required to be 
available for all DataStore implementations (for me, supporting PostGIS 
will be sufficient *g*). But for the sake of completeness, most (major) 
DataSores should get their tag interface, of course.


Cheers
Carsten

___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Carsten Klein]

Andrea,

There is nothing planned to support this functionality. We are more 
interested in nudging people to contribute

open code to benefit everyone.
Unless you're going to write functions that are very specific to your 
case, and would not be of interest to the larger community?


Maybe I didn't explain that correctly. Basically, I'm keen to contribute 
open code so that everyone could benefit from it. However, in this case, 
I only need use two project-specific PostgreSQL functions in WFS 
queries. Likely I'm the only person who needs these. Saying:



"However, I'm planing a private plugin-based (SPI) solution for this."
just means, that I'd like to add a private (my own) GeoTools plugin jar 
to GeoServer's lib dir, that contains these two extra functions. 
GeoTools' SPI approach makes this quite easy. However, it turns out, 
that these functions get not SQL encoded, since these functions' classes 
are not contained in the functions Set of the Store's 
FilterCapabilities. (Actually, the query is split into a pre- and and 
post-filter in the JDBCDataStore.)


Indeed, it would be cool if one can mark a function being "SQL 
encodable" with the same easiness than publishing this function. That 
would be something, others could benefit from as well...


[...]

Or maybe we could have some plugin (a new SPI) that can add entries to 
the capabilities document, given a specific database.


You mean the FilterCapabilies of a specific store? That would be quite 
helpful.


Cheers
Carsten

___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security Policy and CVE handling

[Simone Giannecchini]

+0

Regards,
Simone Giannecchini
==
Online training classes for GeoNode, GeoServer and MapStore from the
experts!
Visit https://www.geosolutionsgroup.com/professional-training/ for more
information.
==
Ing. Simone Giannecchini
@simogeo
Founder/Director GeoSolutions Italy
President GeoSolutions USA

phone: +39 0584 962313
fax: +39 0584 1660272
mob:   +39  333 8128928
US: +1 (845) 547-7905

http://www.geosolutionsgroup.com
http://twitter.com/geosolutions_it

---
This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail.


On Mon, Oct 2, 2023 at 9:56 AM Nuno Oliveira <
nuno.olive...@geosolutionsgroup.com> wrote:

> +1, thank you.
>
> On Mon, Oct 2, 2023 at 8:54 AM Alessio Fabiani <
> alessio.fabi...@geosolutionsgroup.com> wrote:
>
>> +1 Thanks
>>
>> On Sun, Oct 1, 2023 at 9:34 PM Jody Garnett 
>> wrote:
>>
>>> Thanks everyone,
>>>
>>> The motion from September 12th is now passed (its ten day extension now
>>> elapsed).
>>>
>>>
>>>- Alessio Fabiani:
>>>- Andrea Aime: +1
>>>- Ian Turton: +1
>>>- Jody Garnett: +1 initial motion
>>>- Jukka Rahkonen: +1
>>>- Kevin Smith: +1
>>>- Simone Giannecchini:
>>>- Torben Barsballe: +1
>>>- Nuno Oliveira:
>>>
>>>
>>> Community support:
>>>
>>>
>>>- Mark Prins: +1
>>>
>>>
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Oct 1, 2023 at 10:07:34 AM, Rahkonen Jukka <
>>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>>
 +1



 -Jukka Rahkonen-



 *Lähettäjä:* Andrea Aime 
 *Lähetetty:* lauantai 30. syyskuuta 2023 18.47
 *Vastaanottaja:* Jody Garnett 
 *Kopio:* Torben Barsballe ; Geoserver-devel
 ; Alessio Fabiani <
 alessio.fabi...@geosolutionsgroup.com>; Ian Turton ;
 Rahkonen Jukka ; Simone
 Giannecchini ; Nuno
 Oliveira 
 *Aihe:* Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security
 Policy and CVE handling



 +1



 Cheers

 Andrea



 On Sat, Sep 30, 2023 at 12:04 AM Jody Garnett 
 wrote:

 Reminder to vote on this topic, I understand security is a difficult
 topic to discuss in public anyone is welcome to reach out to me directly
 for questions/clarifications.  The proposal has been clarified and refined
 from the questions and response provided thus far.



 Project Steering Committee:



 * Alessio Fabiani:

 * Andrea Aime:

 * Ian Turton:

 * Jody Garnett: +1 initial motion

 * Jukka Rahkonen:

 * Kevin Smith: +1

 * Simone Giannecchini:

 * Torben Barsballe: +1

 * Nuno Oliveira:



 Community support:



 * Mark Prins: +1 "While not eligible to vote I'd like to give my
 thumbs-up for this proposal."



 --

 Jody Garnett





 On Sep 22, 2023 at 9:26:35 AM, Jody Garnett 
 wrote:

 It has been 10 days, I would like to request an extension on this
 proposal as I believe it is good response for the project.



 Jody



 On Fri, Sep 15, 2023 at 11:54 AM Torben Barsballe <
 torbenbarsba...@gmail.com> wrote:

 +1



 The Feedback section read as a little confusing (probably because the
 tone of the document switched from descriptive to conversational). A short
 blurb providing some context at the start, or some indication of personas
 throughout ( i.e. quoted sections being identified as security researchers,
 etc.) would improve legibility. However, since this section is ultimately
 just examples and not procedure, this doesn't affect my vote one way or the
 other.



 Cheers,

 Torben



 On Tue, Sep 12, 2023 at 2:37 PM Jody Garnett 
 wrote:

 Proposal is here: https://github.com/geoserver/geoserver/wiki/GSIP-220



 Overview is using the GitHub "private vulnerability reporting" to
 assign CVE numbers we control to our known security issues.

 --

 Jody Garnett

 ___
 Geoserver-devel mailing list
 Geoserver-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-devel




 --

 Regards,

 Andrea Aime

 ==
 GeoServer Professional Services from the experts!

 Visit http://bit.ly/gs-services-us for more information

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Andrea Aime]

On Mon, Oct 2, 2023 at 12:10 PM Carsten Klein  wrote:

> Seems like the actual problem is, that my new function's class is not
> registered in the PostgreSQL Store's FilterCapabilities. However, I'm
> planing a private plugin-based (SPI) solution for this. How could I modify
> (extend) FilterToSqlHelper.createFilterCapabilities?
>
There is nothing planned to support this functionality. We are more
interested in nudging people to contribute
open code to benefit everyone.
Unless you're going to write functions that are very specific to your case,
and would not be of interest to the larger community?


> Couldn't there be a more extensible way to declare a SPI provided function
> "SQL encodable" for a certain Store (e.g. PostGIS)? Maybe a tag interface
> "SqlEncodable" could do that job?
>
No, it does not make sense... a filter may be sql encodable in one
database, but not in another, and a function is available
for the whole system. I doubt there are many functions that are sql
encodable in all databases we support.

It seems you need something that is specific to your own use case, and also
specific to one database: probably the most appropriate
path is for you to create and register a new data store factory, which ends
up subclassing PostGISDialect and return a different
FilterToSQL implementation (likely a subclass of the existing one).

Or maybe we could have some plugin (a new SPI) that can add entries to the
capabilities document, given a specific database.

Jody, any other ideas?

Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Carsten Klein]

Andrea,

2) Actual function encoding seems only required if functions cannot be 
encoded like "functionName(a1, a2, ..., aN)", that is referred to 
"custom encoding":

https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522

In PostgisFilterToSQL, visit only tries with 
FilterToSqlHelper.visitFunction and, if it did NOT encode the function 
in a custom manner, calls forwards to the super class 
org.geotools.data.jdbc.FilterToSQL, which supports generic function 
encoding:

https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/PostgisFilterToSQL.java#L126

Seems like the actual problem is, that my new function's class is not 
registered in the PostgreSQL Store's FilterCapabilities. However, I'm 
planing a private plugin-based (SPI) solution for this. How could I 
modify (extend) FilterToSqlHelper.createFilterCapabilities?


Couldn't there be a more extensible way to declare a SPI provided 
function "SQL encodable" for a certain Store (e.g. PostGIS)? Maybe a tag 
interface "SqlEncodable" could do that job?


Cheers
Carsten

Am 02.10.2023 um 10:03 schrieb Andrea Aime:

On Mon, Oct 2, 2023 at 9:05 AM Carsten Klein  wrote:

I managed to add a simple function "add", which returns the sum of
both its Double arguments. The add function follows the GeoTools
Function tutorial: it directly implements the Function interface
and gets created by my own FunctionFactory, which is registered
via META-INF/services/org.geotools.filter.FunctionFactory.

However, only the Java implementation is actually used.
GeoTools/GeoServer makes no attempt to encode the "add" function
in SQL when using a PostgreSQL store. What am I missing?

Because you haven't modified the database code to advertise it can 
encode the function, and add the code

to perform the actual encoding. E.g., in the case of PostGIS:

1) Declaration that functions are supported
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L167

2) Actual function encoding:
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522

Another question: most of the built-in functions do not implement
the Function interface directly but extend FunctionExpressionImpl
(which implements FunctionExpression). According to the docs,
these functions must be registered via
META-INF/services/org.geotools.api.filter.Function. So, I added a
"sub" function, returning a - b, which is based on the
FunctionExpression approach (which seems to be quite a bit more
comfortable and newer). Unfortunately, GeoServer/GeoTools seems
not to know the new "sub" function and throws an error when I try
to use that function through a WFS GetFeature request.

The docs are probably pointing you at the wrong registration file, the 
functions are registered in "org.geotools.api.filter.expression.Function":

https://github.com/geotools/geotools/blob/main/modules/library/main/src/main/resources/META-INF/services/org.geotools.api.filter.expression.Function

If you spot issues in the docs please contribute fixes for it.

Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for 
more information.==Ing. Andrea Aime @geowolfTechnical Lead


GeoSolutions Groupphone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549


https://www.geosolutionsgroup.com/ 

http://twitter.com/geosolutions_it 

---


Con riferimento alla normativa sul trattamento dei dati personali 
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati 
“GDPR”), si precisa che ogni circostanza inerente alla presente email 
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui 
conoscenza è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato 
se potesse darmene notizia.This email is intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Andrea Aime]

On Mon, Oct 2, 2023 at 9:05 AM Carsten Klein  wrote:

> I managed to add a simple function "add", which returns the sum of both
> its Double arguments. The add function follows the GeoTools Function
> tutorial: it directly implements the Function interface and gets created by
> my own FunctionFactory, which is registered via
> META-INF/services/org.geotools.filter.FunctionFactory.
>
> However, only the Java implementation is actually used. GeoTools/GeoServer
> makes no attempt to encode the "add" function in SQL when using a
> PostgreSQL store. What am I missing?
>
Because you haven't modified the database code to advertise it can encode
the function, and add the code
to perform the actual encoding. E.g., in the case of PostGIS:

1) Declaration that functions are supported
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L167

2) Actual function encoding:
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522


> Another question: most of the built-in functions do not implement the
> Function interface directly but extend FunctionExpressionImpl (which
> implements FunctionExpression). According to the docs, these functions must
> be registered via META-INF/services/org.geotools.api.filter.Function. So, I
> added a "sub" function, returning a - b, which is based on the
> FunctionExpression approach (which seems to be quite a bit more comfortable
> and newer). Unfortunately, GeoServer/GeoTools seems not to know the new
> "sub" function and throws an error when I try to use that function through
> a WFS GetFeature request.
>
The docs are probably pointing you at the wrong registration file, the
functions are registered in "org.geotools.api.filter.expression.Function":
https://github.com/geotools/geotools/blob/main/modules/library/main/src/main/resources/META-INF/services/org.geotools.api.filter.expression.Function

If you spot issues in the docs please contribute fixes for it.

Cheers
Andrea

==

GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security Policy and CVE handling

[Nuno Oliveira]

+1, thank you.

On Mon, Oct 2, 2023 at 8:54 AM Alessio Fabiani <
alessio.fabi...@geosolutionsgroup.com> wrote:

> +1 Thanks
>
> On Sun, Oct 1, 2023 at 9:34 PM Jody Garnett 
> wrote:
>
>> Thanks everyone,
>>
>> The motion from September 12th is now passed (its ten day extension now
>> elapsed).
>>
>>
>>- Alessio Fabiani:
>>- Andrea Aime: +1
>>- Ian Turton: +1
>>- Jody Garnett: +1 initial motion
>>- Jukka Rahkonen: +1
>>- Kevin Smith: +1
>>- Simone Giannecchini:
>>- Torben Barsballe: +1
>>- Nuno Oliveira:
>>
>>
>> Community support:
>>
>>
>>- Mark Prins: +1
>>
>>
>> --
>> Jody Garnett
>>
>>
>> On Oct 1, 2023 at 10:07:34 AM, Rahkonen Jukka <
>> jukka.rahko...@maanmittauslaitos.fi> wrote:
>>
>>> +1
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> *Lähettäjä:* Andrea Aime 
>>> *Lähetetty:* lauantai 30. syyskuuta 2023 18.47
>>> *Vastaanottaja:* Jody Garnett 
>>> *Kopio:* Torben Barsballe ; Geoserver-devel <
>>> geoserver-devel@lists.sourceforge.net>; Alessio Fabiani <
>>> alessio.fabi...@geosolutionsgroup.com>; Ian Turton ;
>>> Rahkonen Jukka ; Simone
>>> Giannecchini ; Nuno Oliveira
>>> 
>>> *Aihe:* Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security
>>> Policy and CVE handling
>>>
>>>
>>>
>>> +1
>>>
>>>
>>>
>>> Cheers
>>>
>>> Andrea
>>>
>>>
>>>
>>> On Sat, Sep 30, 2023 at 12:04 AM Jody Garnett 
>>> wrote:
>>>
>>> Reminder to vote on this topic, I understand security is a difficult
>>> topic to discuss in public anyone is welcome to reach out to me directly
>>> for questions/clarifications.  The proposal has been clarified and refined
>>> from the questions and response provided thus far.
>>>
>>>
>>>
>>> Project Steering Committee:
>>>
>>>
>>>
>>> * Alessio Fabiani:
>>>
>>> * Andrea Aime:
>>>
>>> * Ian Turton:
>>>
>>> * Jody Garnett: +1 initial motion
>>>
>>> * Jukka Rahkonen:
>>>
>>> * Kevin Smith: +1
>>>
>>> * Simone Giannecchini:
>>>
>>> * Torben Barsballe: +1
>>>
>>> * Nuno Oliveira:
>>>
>>>
>>>
>>> Community support:
>>>
>>>
>>>
>>> * Mark Prins: +1 "While not eligible to vote I'd like to give my
>>> thumbs-up for this proposal."
>>>
>>>
>>>
>>> --
>>>
>>> Jody Garnett
>>>
>>>
>>>
>>>
>>>
>>> On Sep 22, 2023 at 9:26:35 AM, Jody Garnett 
>>> wrote:
>>>
>>> It has been 10 days, I would like to request an extension on this
>>> proposal as I believe it is good response for the project.
>>>
>>>
>>>
>>> Jody
>>>
>>>
>>>
>>> On Fri, Sep 15, 2023 at 11:54 AM Torben Barsballe <
>>> torbenbarsba...@gmail.com> wrote:
>>>
>>> +1
>>>
>>>
>>>
>>> The Feedback section read as a little confusing (probably because the
>>> tone of the document switched from descriptive to conversational). A short
>>> blurb providing some context at the start, or some indication of personas
>>> throughout ( i.e. quoted sections being identified as security researchers,
>>> etc.) would improve legibility. However, since this section is ultimately
>>> just examples and not procedure, this doesn't affect my vote one way or the
>>> other.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Torben
>>>
>>>
>>>
>>> On Tue, Sep 12, 2023 at 2:37 PM Jody Garnett 
>>> wrote:
>>>
>>> Proposal is here: https://github.com/geoserver/geoserver/wiki/GSIP-220
>>>
>>>
>>>
>>> Overview is using the GitHub "private vulnerability reporting" to assign
>>> CVE numbers we control to our known security issues.
>>>
>>> --
>>>
>>> Jody Garnett
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Andrea Aime
>>>
>>> ==
>>> GeoServer Professional Services from the experts!
>>>
>>> Visit http://bit.ly/gs-services-us for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions Group
>>> phone: +39 0584 962313
>>>
>>> fax: +39 0584 1660272
>>>
>>> mob:   +39  339 8844549
>>>
>>>
>>>
>>> https://www.geosolutionsgroup.com/
>>>
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>>
>>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than th

Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security Policy and CVE handling

[Alessio Fabiani]

+1 Thanks

On Sun, Oct 1, 2023 at 9:34 PM Jody Garnett  wrote:

> Thanks everyone,
>
> The motion from September 12th is now passed (its ten day extension now
> elapsed).
>
>
>- Alessio Fabiani:
>- Andrea Aime: +1
>- Ian Turton: +1
>- Jody Garnett: +1 initial motion
>- Jukka Rahkonen: +1
>- Kevin Smith: +1
>- Simone Giannecchini:
>- Torben Barsballe: +1
>- Nuno Oliveira:
>
>
> Community support:
>
>
>- Mark Prins: +1
>
>
> --
> Jody Garnett
>
>
> On Oct 1, 2023 at 10:07:34 AM, Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi> wrote:
>
>> +1
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> *Lähettäjä:* Andrea Aime 
>> *Lähetetty:* lauantai 30. syyskuuta 2023 18.47
>> *Vastaanottaja:* Jody Garnett 
>> *Kopio:* Torben Barsballe ; Geoserver-devel <
>> geoserver-devel@lists.sourceforge.net>; Alessio Fabiani <
>> alessio.fabi...@geosolutionsgroup.com>; Ian Turton ;
>> Rahkonen Jukka ; Simone
>> Giannecchini ; Nuno Oliveira <
>> nuno.olive...@geosolutionsgroup.com>
>> *Aihe:* Re: [Geoserver-devel] Proposal [GSIP 220] - Revised Security
>> Policy and CVE handling
>>
>>
>>
>> +1
>>
>>
>>
>> Cheers
>>
>> Andrea
>>
>>
>>
>> On Sat, Sep 30, 2023 at 12:04 AM Jody Garnett 
>> wrote:
>>
>> Reminder to vote on this topic, I understand security is a difficult
>> topic to discuss in public anyone is welcome to reach out to me directly
>> for questions/clarifications.  The proposal has been clarified and refined
>> from the questions and response provided thus far.
>>
>>
>>
>> Project Steering Committee:
>>
>>
>>
>> * Alessio Fabiani:
>>
>> * Andrea Aime:
>>
>> * Ian Turton:
>>
>> * Jody Garnett: +1 initial motion
>>
>> * Jukka Rahkonen:
>>
>> * Kevin Smith: +1
>>
>> * Simone Giannecchini:
>>
>> * Torben Barsballe: +1
>>
>> * Nuno Oliveira:
>>
>>
>>
>> Community support:
>>
>>
>>
>> * Mark Prins: +1 "While not eligible to vote I'd like to give my
>> thumbs-up for this proposal."
>>
>>
>>
>> --
>>
>> Jody Garnett
>>
>>
>>
>>
>>
>> On Sep 22, 2023 at 9:26:35 AM, Jody Garnett 
>> wrote:
>>
>> It has been 10 days, I would like to request an extension on this
>> proposal as I believe it is good response for the project.
>>
>>
>>
>> Jody
>>
>>
>>
>> On Fri, Sep 15, 2023 at 11:54 AM Torben Barsballe <
>> torbenbarsba...@gmail.com> wrote:
>>
>> +1
>>
>>
>>
>> The Feedback section read as a little confusing (probably because the
>> tone of the document switched from descriptive to conversational). A short
>> blurb providing some context at the start, or some indication of personas
>> throughout ( i.e. quoted sections being identified as security researchers,
>> etc.) would improve legibility. However, since this section is ultimately
>> just examples and not procedure, this doesn't affect my vote one way or the
>> other.
>>
>>
>>
>> Cheers,
>>
>> Torben
>>
>>
>>
>> On Tue, Sep 12, 2023 at 2:37 PM Jody Garnett 
>> wrote:
>>
>> Proposal is here: https://github.com/geoserver/geoserver/wiki/GSIP-220
>>
>>
>>
>> Overview is using the GitHub "private vulnerability reporting" to assign
>> CVE numbers we control to our known security issues.
>>
>> --
>>
>> Jody Garnett
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
>>
>> ==
>> GeoServer Professional Services from the experts!
>>
>> Visit http://bit.ly/gs-services-us for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions Group
>> phone: +39 0584 962313
>>
>> fax: +39 0584 1660272
>>
>> mob:   +39  339 8844549
>>
>>
>>
>> https://www.geosolutionsgroup.com/
>>
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail
>>
>

-- 

Regards,

Alessio Fabiani

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Ing. A

Re: [Geoserver-devel] Custom Database-backed Filter Functions

[Carsten Klein]

I managed to add a simple function "add", which returns the sum of both 
its Double arguments. The add function follows the GeoTools Function 
tutorial: it directly implements the Function interface and gets created 
by my own FunctionFactory, which is registered via 
META-INF/services/org.geotools.filter.FunctionFactory.


However, only the Java implementation is actually used. 
GeoTools/GeoServer makes no attempt to encode the "add" function in SQL 
when using a PostgreSQL store. What am I missing?


Another question: most of the built-in functions do not implement the 
Function interface directly but extend FunctionExpressionImpl (which 
implements FunctionExpression). According to the docs, these functions 
must be registered via 
META-INF/services/org.geotools.api.filter.Function. So, I added a "sub" 
function, returning a - b, which is based on the FunctionExpression 
approach (which seems to be quite a bit more comfortable and newer). 
Unfortunately, GeoServer/GeoTools seems not to know the new "sub" 
function and throws an error when I try to use that function through a 
WFS GetFeature request.


BTW, interface FunctionExpression states:

[...]

 * All implements should be registered for service provider interface
 *
 * 
 * org.geotools.api.filter.Function
 * DefaultFunctionFactor.
 *
 * 
 * If you have a large number of related functions consider the use of 
{@link FunctionFactory}.


[...]

The lines around  and  seem to be mixed up and may be not 
correct (looks like a merge error). Actually most other built-in 
functions are registered in a file


META-INF/services/org.geotools.api.filter.expression.Function

(e.g. org.geotools.data.postgis.filter.FilterFunction_pgNearest). 
However, changing the registration of my "sub" function does not help: 
GeoServer still cannot find that function.


Cheers
Carsten


Am 26.09.2023 um 09:43 schrieb Andrea Aime:
Sort of on track. First class functions have both a java 
implementation and a way to be delegated to

the database.

There are however a few functions that have no equivalent and can be 
run only against a particular database,

like pgNearest:
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/filter/FilterFunction_pgNearest.java

These functions still have to be recognized as part of the filter 
capabilities and have custom encoding code:

https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L196

The downside of these is that they make for a broken system, the 
moment there is more than one backend data source,

or just by the fact of being there.
E.g., pgNearest is always there as postgresql store is always 
included, but installations might be using Oracle, sql server,

shapefiles, all sources where attempting usage of such function will fail.

So it's not clean, but also normally not a big deal because the 
description of functions in WFS capabilities is so poor that clients 
cannot automatically
use them anyways, clients using functions are usually written by hand 
anyways.


Cheers
Andrea


On Tue, Sep 26, 2023 at 9:01 AM Carsten Klein  wrote:

Hi Jody,

thanks for your response :)

Since I will likely not be able to modify/extend FilterToSqlHelper
from a GeoTools Filter Function Plugin, it will be best to focus
on PostgreSQL functions that can be encoded as

functionName(p1, p2, ... pN)

In that case, PostgisFilterToSQL will translate my Java
implemented custom functions to SQL without any further action
required? (Given that "encode functions" is enabled.)

I guess, the actual Java implementation is not required to
return/evaluate any meaningful results based on the arguments,
right? (I won't be able to re-implement e.g. Full Text Search in
Java, of course)

Still on track?

Regards,
Carsten


Am 26.09.2023 um 08:31 schrieb Jody Garnett:

You are running alongside the right track :)

To work you implement in java (for any non PostGIS data) and then
adjust the PostGIS DataStore code to map those functions to SQL.

  * PostGISDialect
  * PostgisFIlterToSQL
  * FilterToSqlHelper
  * FilterToSqlHelper.visitFunction(function,extraData)




You can see the mapping being done from the GeoTools function
data structure (which is why you need a java implementation) to
the SQL.


--
Jody Garnett


On Sep 25, 2023 at 11:23:00 PM, Carsten Klein
 wrote:

Hi there,

I'd like to use some custom PostgreSQL functions as filters in
standard
WFS 2.0.0 requests. The goal is to request features filtered by
e.g.
Full Text Search or the word_similarity function provided by the
pg_trgm
extension (Trig