mirror of
https://github.com/postgres/postgres.git
synced 2026-04-06 01:35:56 -04:00
586dd5d6a5
strncpy() has a well-deserved reputation for being unsafe, so make an effort to get rid of nearly all occurrences in HEAD. A large fraction of the remaining uses were passing length less than or equal to the known strlen() of the source, in which case no null-padding can occur and the behavior is equivalent to memcpy(), though doubtless slower and certainly harder to reason about. So just use memcpy() in these cases. In other cases, use either StrNCpy() or strlcpy() as appropriate (depending on whether padding to the full length of the destination buffer seems useful). I left a few strncpy() calls alone in the src/timezone/ code, to keep it in sync with upstream (the IANA tzcode distribution). There are also a few such calls in ecpg that could possibly do with more analysis. AFAICT, none of these changes are more than cosmetic, except for the four occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength source leads to a non-null-terminated destination buffer and ensuing misbehavior. These don't seem like security issues, first because no stack clobber is possible and second because if your values of sslcert etc are coming from untrusted sources then you've got problems way worse than this. Still, it's undesirable to have unpredictable behavior for overlength inputs, so back-patch those four changes to all active branches. |
||
|---|---|---|
| .. | ||
| compat_informix | ||
| connect | ||
| expected | ||
| performance | ||
| pgtypeslib | ||
| preproc | ||
| sql | ||
| thread | ||
| .gitignore | ||
| ecpg_schedule | ||
| ecpg_schedule_tcp | ||
| Makefile | ||
| Makefile.regress | ||
| pg_regress_ecpg.c | ||
| regression.h | ||
| resultmap | ||