2025-12-21 10:45 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)

[Przemyslaw Czerpak]

2025-12-21 10:45 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* contrib/hbssl/hbssl.hbx
* contrib/hbssl/evppkey.c
+ added new PRG functions:
EVP_PKEY_CTX_get_RSA_PSS_saltlen( <pKeyCTX>, @<nSaltLen> )
-> <nRetCode>
EVP_PKEY_CTX_set_RSA_PSS_saltlen( <pKeyCTX>, <nSaltLen> )
-> <nRetCode>
EVP_PKEY_CTX_get_signature_md( <pKeyCTX>, @<nEvpHash> )
-> <nRetCode>
EVP_PKEY_CTX_set_signature_md( <pKeyCTX>, <nEvpHash> | <cEvpHash> )
-> <nRetCode>
EVP_PKEY_sign_init( <pKeyCTX> ) -> <nRetCode>
EVP_PKEY_sign( <pKeyCTX>, @<cSignature>, <cData> ) -> <nRetCode>
EVP_PKEY_verify_init( <pKeyCTX> ) -> <nRetCode>
EVP_PKEY_verify( <pKeyCTX>, <cSignature>, <cData> ) -> <nRetCode>

* contrib/hbssl/hbssl.hbx
* contrib/hbssl/x509.c
+ added new PRG function:
X509_get_serialNumber( <pX509> ) -> <nSerialNum>

* src/rtl/base64d.c
* indenting
; question: With small modification we can add support for base64url
encoding (with additional parameter passed to hb_base64encode())
and decoding (can be done automatically by hb_base64decode()).
Do you think it's worth to do or it's such simple thing that
we should keep the code clean and user can make necessary
conversions themselves.

best regards
Przemek

[Lorenzo Fiorini]

Many thanks, Przemyslaw.

To answer your question I checked my code and I found that I still use these functions from hbtip:

tip_urldecode
tip_urlencode

tip_filemimetype
tip_htmlspecialchars
tip_timestampgmt

Having equivalents in the core would mean code more tested and less dependencies.

Regards,
Lorenzo

-- 

[Lailton Fernando Mariano]

Yes, I totally agree :)

Thanks Przemyslaw.

[Bacco]

question: With small modification we can add support for base64url
                encoding (with additional parameter passed to hb_base64encode())
                and decoding (can be done automatically by hb_base64decode()).
                Do you think it's worth to do or it's such simple thing that
                we should keep the code clean and user can make necessary

                conversions themselves.

I believe it can be a bool in the original encode and decode functions, so

in the absence of a .t. both retain current behaviour (it would be easy to

do an autodecode that detect the 2 sets of characters, but I believe it would

be undesirable to allow the alternative characters where they aren't supposed

to occur. Also, it would be good to document the behaviour of the == padding

characters in both cases.

RANDOM THOUGHTS:

An alternative to all these kind of functions is, instead of hardcoding multiple

character sets, is to allow user to provide his own set.of chars (and provide

some default sets defined in headers, so one can do

hb_Base64Encode(...,..., BASE64URL)

having

#define BASE64URL  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_"

somewhere in default headers

Sam logic can be adopted in

hb_NumToHex(...,..., BASE16SEXADECIMAL)

having

#define BASE64SEXADECIMAL "0123456789KSNJFL"

somewhere in default headers

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/367729ed-4cfe-4fa4-bb45-500e5403b19cn%40googlegroups.com.

[Bacco]

... what makes me think that perhaps the solution would

be a generic base converter function where we provide various

bases in #defines, so one can apply the same function to multiple

bases, including both I mentioned;

Again, just random thoughts to increase the scope creep :D