Re: [hackers] [tabbed] bump version to 0.7 || Hiltjo Posthuma

[Joerg Jung]

> On 12. Oct 2022, at 23:04, Hiltjo Posthuma  wrote:
> On Wed, Oct 12, 2022 at 08:41:37PM +0200, Joerg Jung wrote:
>> Looks like the 0.7 release tarball seems 
>> to miss the xembed.1 man page.
>> I guess because dist: target in makefile was not
>> updated to include file?
> Thanks for reporting it,

I see you fixed it in repo already, thanks!

Please, can you also do a new release tarball? 
i.e. 0.7.1 or similar, so that this can be packaged/updated 
in distros as well.

Thanks,
Regards
Joerg

Re: [hackers] [tabbed] bump version to 0.7 || Hiltjo Posthuma

[Joerg Jung]

Looks like the 0.7 release tarball seems 
 to miss the xembed.1 man page.
I guess because dist: target in makefile was not
 updated to include file?

> Am 04.10.2022 um 19:39 schrieb g...@suckless.org:
> 
> commit b372f9ce28610dc8dd860abd42f9837972bc5adb
> Author: Hiltjo Posthuma 
> AuthorDate: Tue Oct 4 19:38:44 2022 +0200
> Commit: Hiltjo Posthuma 
> CommitDate: Tue Oct 4 19:38:44 2022 +0200
> 
>bump version to 0.7
> 
> diff --git a/config.mk b/config.mk
> index 29caa84..4bd0a40 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -1,5 +1,5 @@
> # tabbed version
> -VERSION = 0.6
> +VERSION = 0.7
> 
> # Customize below to fit your system
> 
> 

Re: [hackers] [sic] bump version to 1.4 || Hiltjo Posthuma

[Joerg Jung]

I wonder why this does not show up here?
http://git.suckless.org/sic/ 

> On 4. Oct 2022, at 19:29, g...@suckless.org wrote:
> 
> commit d028623f079c5c8fcdcc9ed9925a0d79dfd2c940
> Author: Hiltjo Posthuma 
> AuthorDate: Tue Oct 4 19:28:52 2022 +0200
> Commit: Hiltjo Posthuma 
> CommitDate: Tue Oct 4 19:28:52 2022 +0200
> 
>bump version to 1.4
> 
> diff --git a/Makefile b/Makefile
> index 58efc9f..2cad750 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
> .POSIX:
> 
> NAME = sic
> -VERSION = 1.3
> +VERSION = 1.4
> 
> # paths
> PREFIX = /usr/local
> 

Re: [hackers] [sic] add support for pledge()

[Joerg Jung]

> On 22 Aug 2016, at 11:19, Anselm R Garbe  wrote:
> On 14 August 2016 at 11:11, Hiltjo Posthuma  wrote:
>> In general we should try to avoid ifdefs asmuch as possible. But I would not
>> mind the pledge in the form:
>> 
>>#ifdef __OpenBSD__
>>if (pledge("stdio", NULL) == -1)
>>eprint("error: pledge:");
>>#endif
>> 
>> Also in my opinion we should just import the OpenBSD strlcpy() version or
>> rename the current one, it has not the same behaviour as strlcpy and is
>> confusing.
>> 
>> Attached is my proposed patch.
> 
> ACK

…back on this topic, makes one feel like a corpse vulture :)
Any chance to get this committed?

Re: [hackers] [sic] add support for pledge()

[Joerg Jung]

> On 14 Aug 2016, at 11:11, Hiltjo Posthuma  wrote:
> 
> On Sun, Aug 14, 2016 at 12:30:46AM +0200, Joerg Jung wrote:
>> Hi,
>> 
>> please find below a diff for sic to enable pledge() to be used on
>> OpenBSD.  This diff was originally submitted by Ali H. Fardan via
>> po...@openbsd.org.  While here, I enabled the usage of strlcpy()
>> from libc on OpenBSD. 
>> 
>> Honestly, I'm not sure about how such portability goo should be 
>> handled the suckless way, but since I see similar #ifdef __linux__
>> instances in slock, I guess the proposed way is okay?
>> 
>> Thanks,
>> Regards,
>> Joerg
>> 
>> 
>> diff --git a/sic.c b/sic.c
>> index ce6d216..b22ea06 100644
>> --- a/sic.c
>> +++ b/sic.c
>> @@ -182,6 +182,8 @@ main(int argc, char *argv[]) {
>>  setbuf(stdout, NULL);
>>  setbuf(srv, NULL);
>>  setbuf(stdin, NULL);
>> +if (pledge("stdio", NULL) == -1)
>> +eprint("error: pledge:");
>>  for(;;) { /* main loop */
>>  FD_ZERO(&rd);
>>  FD_SET(0, &rd);
>> diff --git a/util.c b/util.c
>> index 8afa58f..88ea06e 100644
>> --- a/util.c
>> +++ b/util.c
>> @@ -40,12 +40,16 @@ dial(char *host, char *port) {
>>  return srv;
>> }
>> 
>> +#ifndef __OpenBSD__
>> +#define pledge(promises, paths) 0
>> +
>> #define strlcpy _strlcpy
>> static void
>> strlcpy(char *to, const char *from, int l) {
>>  memccpy(to, from, '\0', l);
>>  to[l-1] = '\0';
>> }
>> +#endif
>> 
>> static char *
>> eat(char *s, int (*p)(int), int r) {
>> 
> 
> Hi,
> 
> In general we should try to avoid ifdefs asmuch as possible. But I would not
> mind the pledge in the form:
> 
>   #ifdef __OpenBSD__
>   if (pledge("stdio", NULL) == -1)
>   eprint("error: pledge:");
>   #endif
> 
> Also in my opinion we should just import the OpenBSD strlcpy() version or
> rename the current one, it has not the same behaviour as strlcpy and is
> confusing.
> 
> Attached is my proposed patch.

Fine with me.

[hackers] [sic] add support for pledge()

[Joerg Jung]

Hi,

please find below a diff for sic to enable pledge() to be used on
OpenBSD.  This diff was originally submitted by Ali H. Fardan via
po...@openbsd.org.  While here, I enabled the usage of strlcpy()
from libc on OpenBSD. 

Honestly, I'm not sure about how such portability goo should be 
handled the suckless way, but since I see similar #ifdef __linux__
instances in slock, I guess the proposed way is okay?

Thanks,
Regards,
Joerg


diff --git a/sic.c b/sic.c
index ce6d216..b22ea06 100644
--- a/sic.c
+++ b/sic.c
@@ -182,6 +182,8 @@ main(int argc, char *argv[]) {
setbuf(stdout, NULL);
setbuf(srv, NULL);
setbuf(stdin, NULL);
+   if (pledge("stdio", NULL) == -1)
+   eprint("error: pledge:");
for(;;) { /* main loop */
FD_ZERO(&rd);
FD_SET(0, &rd);
diff --git a/util.c b/util.c
index 8afa58f..88ea06e 100644
--- a/util.c
+++ b/util.c
@@ -40,12 +40,16 @@ dial(char *host, char *port) {
return srv;
 }
 
+#ifndef __OpenBSD__
+#define pledge(promises, paths) 0
+
 #define strlcpy _strlcpy
 static void
 strlcpy(char *to, const char *from, int l) {
memccpy(to, from, '\0', l);
to[l-1] = '\0';
 }
+#endif
 
 static char *
 eat(char *s, int (*p)(int), int r) {

Re: [hackers] Re: [e...@faurot.net: Re: problem with gethostbyaddr() on OBSD 5.4?]

[Joerg Jung]

Ooopps, ... wrong hackers list... Sorry for the noise!

Am 06.02.2014 um 12:23 schrieb Joerg Jung :

> Am 05.02.2014 um 17:20 schrieb Stuart Henderson :
> 
>> On 2014/02/05 11:10, Simon Perreault wrote:
>>> Le 2014-02-05 03:33, Eric Faurot a écrit :
>>>> Just a question before I commit it.  The '/' character is apparently
>>>> used in dname labels sometimes.  Can anyone think of other chars that
>>>> should be allowed too?  Or do we want to be even more lenient wrt dname
>>>> validation? 
>>> 
>>> Why validate at all? Strictly speaking, all bytes are allowed in DNS
>>> labels...
>> 
>> Right - the usual restriction "letters, digits or hyphens" is on host
>> names only, not DNS labels.
> 
> I do not think so. As stated in 
> http://tools.ietf.org/search/rfc6672#section-2.1 
> 
> The DNAME target is a domain name as defined in
> http://tools.ietf.org/search/rfc1035 Section 2.3.1
> 
>> https://tools.ietf.org/html/rfc6672#section-6.2
>> 
>>  The advisory remarks in [RFC2317] concerning the choice of the "/"
>>  character apply here as well.
> 
> Yes, but only for _reverse_ delegations.
> 
>> https://tools.ietf.org/html/rfc2317 (section 4)
>> 
>>  Some DNS implementations are not kind to special characters in domain
>>  names, e.g. the "/" used in the above examples.  As [3] makes clear,
>>  these are legal, though some might feel unsightly.  Because these are
>>  not host names the restriction of [2] does not apply.  Modern clients
>>  and servers have an option to act in the liberal and correct fashion.
>> 
>> 
>> [3] https://tools.ietf.org/html/rfc2181#section-11
> 
> This one is obsolete and updated by others.
> 
>> "  The DNS itself places only one restriction on the particular labels
>>  that can be used to identify resource records.  That one restriction
>>  relates to the length of the label and the full name.  The length of
>>  any one label is limited to between 1 and 63 octets.  A full domain
>>  name is limited to 255 octets (including the separators).  The zero
>>  length full name is defined as representing the root of the DNS tree,
>>  and is typically written and displayed as ".".  Those restrictions
>>  aside, any binary string whatever can be used as the label of any
>>  resource record. "
> 
> 
> 

[hackers] Re: [e...@faurot.net: Re: problem with gethostbyaddr() on OBSD 5.4?]

[Joerg Jung]

Am 05.02.2014 um 17:20 schrieb Stuart Henderson :

> On 2014/02/05 11:10, Simon Perreault wrote:
>> Le 2014-02-05 03:33, Eric Faurot a écrit :
>>> Just a question before I commit it.  The '/' character is apparently
>>> used in dname labels sometimes.  Can anyone think of other chars that
>>> should be allowed too?  Or do we want to be even more lenient wrt dname
>>> validation? 
>> 
>> Why validate at all? Strictly speaking, all bytes are allowed in DNS
>> labels...
> 
> Right - the usual restriction "letters, digits or hyphens" is on host
> names only, not DNS labels.

I do not think so. As stated in 
http://tools.ietf.org/search/rfc6672#section-2.1 

The DNAME target is a domain name as defined in
http://tools.ietf.org/search/rfc1035 Section 2.3.1

> https://tools.ietf.org/html/rfc6672#section-6.2
> 
>   The advisory remarks in [RFC2317] concerning the choice of the "/"
>   character apply here as well.

Yes, but only for _reverse_ delegations.

> https://tools.ietf.org/html/rfc2317 (section 4)
> 
>   Some DNS implementations are not kind to special characters in domain
>   names, e.g. the "/" used in the above examples.  As [3] makes clear,
>   these are legal, though some might feel unsightly.  Because these are
>   not host names the restriction of [2] does not apply.  Modern clients
>   and servers have an option to act in the liberal and correct fashion.
> 
> 
> [3] https://tools.ietf.org/html/rfc2181#section-11

This one is obsolete and updated by others.

> "  The DNS itself places only one restriction on the particular labels
>   that can be used to identify resource records.  That one restriction
>   relates to the length of the label and the full name.  The length of
>   any one label is limited to between 1 and 63 octets.  A full domain
>   name is limited to 255 octets (including the separators).  The zero
>   length full name is defined as representing the root of the DNS tree,
>   and is typically written and displayed as ".".  Those restrictions
>   aside, any binary string whatever can be used as the label of any
>   resource record. "