Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

2020-08-30 Thread oldk1331
On 8/30/20 9:51 PM, Waldek Hebisch wrote:
> On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
>>
>> Hi Waldek,
>>
>> Your commit e68c2a3e doesn't work out of box on my system:
>>
>> The gcc or glibc on my system is hardened (might be true
>> for newer gcc/glibc on other systems as well), so it
>> actually checks for buffer overflow in 'strcpy', so the
>> error message I described in the first mail still presents,
>> so we need to change sockio-c.c#929 to
>>
>> strncpy(server[1].addr.u_addr.sa_data, name, ??);
>>
>> I'm not sure about the struct layout here, which number
>> should be put there?
> 
> 30.  However, I think that attached patch is better.
> 

OK, I tested it and found 2 issues:

1. you need to change "open_server" as well.
2. the memset destroys the first 2 bits of the addr struct,
causing failure to "bind".

(BTW, isn't strncpy theoretically safer?)

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0418b271-0830-1a82-4d52-fe045aaf3eb9%40gmail.com.


Re: [fricas-devel] patch propagate PACKAGE_*

2020-08-30 Thread Ralf Hemmecke
> In https://github.com/hemmecke/fricas-doc/Makefile I see somewhat
> disturbing text:
> 
> # Out-of-source builds are not supported

Yes, but since fricas-doc is not going to be the target, it's
unimportant. That was how I collected part of the fricas.github.io data.

Of course the documentation patch will be tested for in-source and
out-of-source builds.

> Yes, I like to have code and documentation in the same repository.

Thanks. That makes things clear.

Ralf

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/800cd1df-25ac-9af2-4a7f-4360cde479e5%40hemmecke.de.


Re: [fricas-devel] patch propagate PACKAGE_*

2020-08-30 Thread Waldek Hebisch
On Sun, Aug 30, 2020 at 09:06:08AM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
> 
> > Concerning PACKAGE_ stuff, part of it is bloat forced by configure,
> > few are used to print messages.  If you want new message, then add
> > all code needed to support it. But ATM the patch look incomplete...
> 
> OK, I feared that you will criticize that patch, so I first proposed it
> on the mailing list.
> 
> I am currently work on putting all stuff for generating the book and
> fricas.github.io into fricas so that everyone can generate the website
> and also a local (offline) version of it. Of course, I can hardcode the
> data that is already in configure.ac, but I don't like to double data.
> You probably see that it makes sense to have also PACKAGE_NAME,
> PACKAGE_BUGREPORT, and PACKAGE_URL available to show them in the
> documentation.

OK.

> Of course, that patch must look incomplete now, but I thought it's small
> enough to go in before the big documentation patch.

Well, if this make things simpler for you, then go on.  I find such
small changes more readible in context, that is as part of bigger
change.

> That brings me to another question, before I spend even more time on it
> and then get rejected...
> 
> Formerly, I used another (GPL) repository
> https://github.com/hemmecke/fricas-doc to generate fricas.github.io, but
> that looked unnecessarirly artificial to me, since I need the fricas
> sources in order to generate book and website. The only information that
> fricas-doc actually added was a few .rst files. So now I develop a
> branch on top of fricas master with all the information and
> build-machinery in it. Since I rebase and change commits quite a lot, I
> have not proposed it yet officially, but if anyone wants to look and
> criticize it, it is at:
> 
> https://github.com/hemmecke/fricas/commits/formatted
> 
> The last commits are rather messy... they will be cleaned up.

In https://github.com/hemmecke/fricas-doc/Makefile I see somewhat
disturbing text:

# Out-of-source builds are not supported


> Anyway, the question is whether *you* like the idea of having code and
> documentation/website in the same repository. Of course, I would like to
> have it that way, because splitting docs and code doesn't make sense for
> for me for our rather small repository and I wanted to avoid git
> submodules or other stuff to sync the documentation and code versions.

Yes, I like to have code and documentation in the same repository.

> Ralf
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to fricas-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/2b354a71-6354-2aaa-9fa0-2871a6e61fcd%40hemmecke.org.

-- 
  Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200830144631.GB39147%40math.uni.wroc.pl.


Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

2020-08-30 Thread Waldek Hebisch
On Sun, Aug 30, 2020 at 08:39:32PM +0800, oldk1331 wrote:
> 
> Hi Waldek,
> 
> Your commit e68c2a3e doesn't work out of box on my system:
> 
> The gcc or glibc on my system is hardened (might be true
> for newer gcc/glibc on other systems as well), so it
> actually checks for buffer overflow in 'strcpy', so the
> error message I described in the first mail still presents,
> so we need to change sockio-c.c#929 to
> 
> strncpy(server[1].addr.u_addr.sa_data, name, ??);
> 
> I'm not sure about the struct layout here, which number
> should be put there?

30.  However, I think that attached patch is better.
-- 
  Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20200830135116.GA39147%40math.uni.wroc.pl.
diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index 30e0eba..57baf71 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -752,13 +752,15 @@ connect_to_local_server(char *server_name, int purpose, int time_out)
 return NULL;
   }
   /* connect socket using name specified in command line */
-  memset(server[1].addr.u_addr.sa_data, 0,
- sizeof(server[1].addr.u_addr.sa_data));
+  memset(server[1].addr.pad, 0,
+ sizeof(server[1].addr.pad));
   sock->addr.u_addr.sa_family = FRICAS_AF_LOCAL;
-  strcpy(sock->addr.u_addr.sa_data, name);
+  strcpy(sock->addr.pad +
+  ((char *)(&(sock->addr.u_addr.sa_data))
+   -(char *)(&(sock->addr.u_addr))), name);
   for(i=0; isocket, >addr.u_addr,
-   sizeof(sock->addr.u_addr));
+   sizeof(sock->addr.pad));
 if (code == -1) {
   if (
 /* @@@ Why we need this */


Re: [fricas-devel] an interesting bug, regarding sman (low level C stuff)

2020-08-30 Thread oldk1331
On 8/28/20 11:23 PM, oldk1331 wrote:
> On 8/28/20 9:35 PM, Waldek Hebisch wrote:
>> the hack I proposed is not nice, it is similar to
>> hacks that are probably in use in similar contexts:
>> C compiler have to tolerate access beyond declared
>> size to struct because lot of C code uses it.  So
>> I see no point of going in direction you propose.
>>
> 
> OK, I agree with your explanation now, please commit
> your solution.
> 
> - Qian
> 

Hi Waldek,

Your commit e68c2a3e doesn't work out of box on my system:

The gcc or glibc on my system is hardened (might be true
for newer gcc/glibc on other systems as well), so it
actually checks for buffer overflow in 'strcpy', so the
error message I described in the first mail still presents,
so we need to change sockio-c.c#929 to

strncpy(server[1].addr.u_addr.sa_data, name, ??);

I'm not sure about the struct layout here, which number
should be put there?

- Qian

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/58afe5e0-ae20-a0cc-ecc2-2870454f5765%40gmail.com.


Re: [fricas-devel] patch propagate PACKAGE_*

2020-08-30 Thread Ralf Hemmecke
Hi Waldek,

> Concerning PACKAGE_ stuff, part of it is bloat forced by configure,
> few are used to print messages.  If you want new message, then add
> all code needed to support it. But ATM the patch look incomplete...

OK, I feared that you will criticize that patch, so I first proposed it
on the mailing list.

I am currently work on putting all stuff for generating the book and
fricas.github.io into fricas so that everyone can generate the website
and also a local (offline) version of it. Of course, I can hardcode the
data that is already in configure.ac, but I don't like to double data.
You probably see that it makes sense to have also PACKAGE_NAME,
PACKAGE_BUGREPORT, and PACKAGE_URL available to show them in the
documentation.

Of course, that patch must look incomplete now, but I thought it's small
enough to go in before the big documentation patch.

That brings me to another question, before I spend even more time on it
and then get rejected...

Formerly, I used another (GPL) repository
https://github.com/hemmecke/fricas-doc to generate fricas.github.io, but
that looked unnecessarirly artificial to me, since I need the fricas
sources in order to generate book and website. The only information that
fricas-doc actually added was a few .rst files. So now I develop a
branch on top of fricas master with all the information and
build-machinery in it. Since I rebase and change commits quite a lot, I
have not proposed it yet officially, but if anyone wants to look and
criticize it, it is at:

https://github.com/hemmecke/fricas/commits/formatted

The last commits are rather messy... they will be cleaned up.

Anyway, the question is whether *you* like the idea of having code and
documentation/website in the same repository. Of course, I would like to
have it that way, because splitting docs and code doesn't make sense for
for me for our rather small repository and I wanted to avoid git
submodules or other stuff to sync the documentation and code versions.

Ralf

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2b354a71-6354-2aaa-9fa0-2871a6e61fcd%40hemmecke.org.