[devel] IA: destination buffer overflow

[devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

Hi,

Ещё раз обратите внимание,

$ fgrep -l 'will always overflow destination buffer' *
adesklets-0.6.1-alt1
avinfo-1.0-alt1.a16
axiom-1:3.2007.09-alt2
conntrack-tools-0.9.3-alt0.1
dlume-0.2.4-alt1
dosfstools-2.11-alt4
dstool-2.0-alt2
fceultra-0.98.13-alt1
freedroidrpg-0.10.2-alt1
gerbv-1.0.1-alt1.1
hping3-0.0.20051105-alt2
httrack-3.40.2-alt1
hydra-5.3-alt2.0
icebreaker-1:1.9.5-alt1
libclip-1.2.0cvs-alt1
libhdf5-1.6.6-alt1
libshout-1.0.9-alt4
maui-3.2.6p19-alt1
mcrypt-2.6.4-alt2
mgetty-1.1.31-alt1.1
MySQL41-4.1.21-alt5.1
powernowd-0.95-alt2
qico.xe-0.57.1-alt11
spcaview-20061208-alt1
sphinx3-0.6-alt1
wwwoffle-2.9-alt1
xplanet-1.2.0-alt2

Т.е. эти пакеты содердат код, при достижении которого во время работы
всегда будет происходить abort().

Кроме того,
$ fgrep -l 'might overflow destination buffer' *
beep-1:0.9.7.1-alt0.3
blender-2.45-alt2
callweaver-1.1.99.200710171625-alt1
clamsmtp-1.9-alt1
compiz-0.6.2-alt3
crossfire-1.10.0-alt1
dlume-0.2.4-alt1
dmenu-3.2-alt1
dvdauthor-0.6.12-alt2.2.1
empty-0.6.12b-alt1
evms-2.5.5-alt6
freeradius-1.1.7-alt2
fuse-zfs-0.4.0_beta1.hg20070527-alt1
ganglia-3.0.4-alt2
gftp-2.0.18stable-alt3.1
gnuitar-0.3.1-alt1
gputils-0.13.4-alt0.1
grcm-0.1.5-alt3
k9copy-1.2.0-alt1
lam-7.1.4-alt1
lesstif-0.95-alt2
libcompizconfig-0.6.0-alt1
libdb4.3-4.3.29-alt4
libdb4.4-4.4.20-alt2
libdvdnav-0.1.10-alt3
libxview-3.2p1.4-alt5
motion-3.2.8-alt2
mplayer-1.0-alt35.25029.1
multitail-5.2.0-alt1
mythtv-0.21.0-alt0.svn20071121
netcat-4.0.20061122-alt1
openmotif-2.2.3-alt3.1
pilot-link-0.12.2-alt2
pine-4.64L-alt4.1
ppp-2.4.4-alt8
qiv-1:2.1-alt3.pre12
radiusclient-ng-0.5.3-alt2
sane-1.0.18-alt5
siege-2.65-alt0.1.1
snort-2.4.5-alt2.1
soundtracker-0.6.8-alt3
ss5-3.6.1-alt1
syslog-ng-2.0.5-alt1
vcdimager-0.7.23-alt2


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> Ещё раз обратите внимание,
> $ fgrep -l 'will always overflow destination buffer' *
> mgetty-1.1.31-alt1.1

Ну и чё с этим предлагается делать maintainerus vulgaris?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Sun, Nov 25, 2007 at 09:55:20PM +0200, Michael Shigorin wrote:
> On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> > Ещё раз обратите внимание,
> > $ fgrep -l 'will always overflow destination buffer' *
> > mgetty-1.1.31-alt1.1
> 
> Ну и чё с этим предлагается делать maintainerus vulgaris?

Орфанить я буду эти пакеты, неужели не очевидно ещё?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Igor Zubkov]

25.11.07, Dmitry V. Levin<ldv@altlinux.org> написал(а):
> On Sun, Nov 25, 2007 at 09:55:20PM +0200, Michael Shigorin wrote:
> > On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> > > Ещё раз обратите внимание,
> > > $ fgrep -l 'will always overflow destination buffer' *
> > > mgetty-1.1.31-alt1.1
> >
> > Ну и чё с этим предлагается делать maintainerus vulgaris?
>
> Орфанить я буду эти пакеты, неужели не очевидно ещё?

Тогда просьба заорфанить dlume-0.2.4-alt1 сейчас, а не потом.

-- 
icesik

Re: [devel] IA: destination buffer overflow

[Slava Semushin]

2007/11/26, Michael Shigorin <mike / osdn.org.ua>:
> On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> > Ещё раз обратите внимание,
> > $ fgrep -l 'will always overflow destination buffer' *
> > mgetty-1.1.31-alt1.1
> Ну и чё с этим предлагается делать maintainerus vulgaris?

# TODO:
# - 1.1.35 (some patches need review/rediffing)

:) Возможно, это исправлено в новой версии? Ну или хотя бы diff между
версиями глянуть, обращая внимания на исправления около str* ф-ций.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Sun, Nov 25, 2007 at 09:55:20PM +0200, Michael Shigorin wrote:

>> Ещё раз обратите внимание,
>> $ fgrep -l 'will always overflow destination buffer' *
>> mgetty-1.1.31-alt1.1
MS> Ну и чё с этим предлагается делать maintainerus vulgaris?

Искать причины. Прошлый раз когда был набег на эту тему у в моих пакетах
дело было в тривиально неправильнм размере выделяемого статического
буфера.

Если дело в этом -- то будет тривиальный патчик.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Пользуйтесь, кому не страшно ;-)
		-- vvzhy in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Mon, Nov 26, 2007 at 12:16:32AM +0300, Dmitry V. Levin wrote:

>> On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> >> Ещё раз обратите внимание,
> >> $ fgrep -l 'will always overflow destination buffer' *
> >> mgetty-1.1.31-alt1.1
>> Ну и чё с этим предлагается делать maintainerus vulgaris?
DVL> Орфанить я буду эти пакеты, неужели не очевидно ещё?

С ppp чуток подожди -- я постараюсь на этой неделе с ним разобраться.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Большой программе - большие глюки.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Sergey Y. Afonin]

On Sunday 25 November 2007, Dmitry V. Levin wrote:

> Ещё раз обратите внимание,
> 
> $ fgrep -l 'will always overflow destination buffer' *
 
Вопрос чуть в сторону. А каким тестом это выявлено ? Или это
gcc умный стал и куда-то в бинарник включает ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] IA: destination buffer overflow

[Slava Semushin]

2007/11/26, Slava Semushin <slava.semushin / gmail.com>:
> 2007/11/26, Michael Shigorin <mike / osdn.org.ua>:
> > On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> > > Ещё раз обратите внимание,
> > > $ fgrep -l 'will always overflow destination buffer' *
> > > mgetty-1.1.31-alt1.1
> > Ну и чё с этим предлагается делать maintainerus vulgaris?
> :) Возможно, это исправлено в новой версии?
[...]

Вот что есть в ChangeLog'е:

Это для 1.1.34:

        * voice/libvoice/record.c: fix (non-exploitable) 1-byte buffer
          overflow in construction of RMD file header

Это для 1.1.32:

        * voice/libpvf/wav.c, voice/pvftools/pvfcut.c, pvfecho.c,
        pvfreverse.c: fix realloc(NULL) induced core dumps on older OSes

Велика вероятность, что исправлены именно эти ошибки.

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Slava Semushin]

2007/11/26, Sergey Y. Afonin <asy / altlinux.ru>:
[...]
> Вопрос чуть в сторону. А каким тестом это выявлено ? Или это
> gcc умный стал и куда-то в бинарник включает ?

gcc с опцией -fstack-protector


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Damir Shayhutdinov]

> > Вопрос чуть в сторону. А каким тестом это выявлено ? Или это
> > gcc умный стал и куда-то в бинарник включает ?
>
> gcc с опцией -fstack-protector
gcc с опцией -D_FORTIFY_SOURCE=2

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Mon, Nov 26, 2007 at 12:16:32AM +0300, Dmitry V. Levin wrote:
> > > Ещё раз обратите внимание,
> > > $ fgrep -l 'will always overflow destination buffer' *
> > > mgetty-1.1.31-alt1.1
> > Ну и чё с этим предлагается делать maintainerus vulgaris?
> Орфанить я буду эти пакеты, неужели не очевидно ещё?

Почему?  Я не буду цепляться зубами за mgetty, но у нас в
orphaned и так достаточно пакетов, которые имеют ненулевую
ценность в том виде, в каком они есть -- если чётко обозначить, 
что это contrib.

Дима, трамвайные колеи никогда не будут выверены до микрона.
Стоит abort -- и пусть себе.  Достаточно.

PS: патчи принимаются.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Mon, Nov 26, 2007 at 02:25:44PM +0600, Slava Semushin wrote:
> > > Ещё раз обратите внимание,
> > > $ fgrep -l 'will always overflow destination buffer' *
> > > mgetty-1.1.31-alt1.1
> > Ну и чё с этим предлагается делать maintainerus vulgaris?
> # TODO:
> # - 1.1.35 (some patches need review/rediffing)
> :) Возможно, это исправлено в новой версии? Ну или хотя бы diff
> между версиями глянуть, обращая внимания на исправления около
> str* ф-ций.

Поскольку мне негде проверить быстро, а городить стенд --
медленно, то не стал устраивать слишком больших изменений.
Кажется, там ещё и часть патчей отъезжала.

У предыдущего сборщика картинка примерно такая же.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Mon, Nov 26, 2007 at 11:51:51AM +0300, Денис Смирнов wrote:
> >> Ещё раз обратите внимание,
> >> $ fgrep -l 'will always overflow destination buffer' *
> >> mgetty-1.1.31-alt1.1
> MS> Ну и чё с этим предлагается делать maintainerus vulgaris?
> Искать причины. Прошлый раз когда был набег на эту тему у в
> моих пакетах дело было в тривиально неправильнм размере
> выделяемого статического буфера.  Если дело в этом -- то будет
> тривиальный патчик.

Мне порой стыдно читать патчи, которые присылают, но факт в том,
что тратить своё время на их составление будет непродуктивно.
Плохой из меня сишник, и лучше становиться не в планах.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Mon, Nov 26, 2007 at 03:08:07PM +0600, Slava Semushin wrote:
> > > > Ещё раз обратите внимание,
> > > > $ fgrep -l 'will always overflow destination buffer' *
> > > > mgetty-1.1.31-alt1.1
> > > Ну и чё с этим предлагается делать maintainerus vulgaris?
> > :) Возможно, это исправлено в новой версии?
> Вот что есть в ChangeLog'е:
> 
> Это для 1.1.34:
> 
>         * voice/libvoice/record.c: fix (non-exploitable) 1-byte buffer
>           overflow in construction of RMD file header
> 
> Это для 1.1.32:
> 
>         * voice/libpvf/wav.c, voice/pvftools/pvfcut.c, pvfecho.c,
>         pvfreverse.c: fix realloc(NULL) induced core dumps on older OSes
> 
> Велика вероятность, что исправлены именно эти ошибки.

Ну если хочешь -- пособирай.  Ноту выписывать?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Slava Semushin]

2007/11/26, Michael Shigorin <mike / osdn.org.ua>:
[...]
> > Велика вероятность, что исправлены именно эти ошибки.
> Ну если хочешь -- пособирай.  Ноту выписывать?

Нет, спасибо. Если вдруг соберу, то положу в git, чтобы ты посмотрел и смержил.

P.S. А надо? Могу попробовать собрать новую версию (с претиркой
патчей), а, если не получится, то тогда можно попытаться сбэкпортить
фикс для этой ошибки на нашу версию. Надо?

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Mon, Nov 26, 2007 at 04:28:41PM +0600, Slava Semushin wrote:
> > > Велика вероятность, что исправлены именно эти ошибки.
> > Ну если хочешь -- пособирай.  Ноту выписывать?
> Нет, спасибо. Если вдруг соберу, то положу в git, чтобы ты
> посмотрел и смержил.
> 
> P.S. А надо? Могу попробовать собрать новую версию (с претиркой
> патчей), а, если не получится, то тогда можно попытаться
> сбэкпортить фикс для этой ошибки на нашу версию. Надо?

Я бы пытался перетащить патчи на текущую версию или повыкидывать
их -- это более осмысленная работа, чем бэкпорт исправлений.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> k9copy-1.2.0-alt1
fixed in 1.2.0-alt2


-- 

С уважением,
Алексей Морсов
программист ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
ICQ: 196766290
www.ricom.ru
www.fondmarket.ru

ALT Linux Team Member
email: swi@altlinux.ru
web: www.altlinux.ru, www.sisyphus.ru



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Mon, Nov 26, 2007 at 12:12:55PM +0200, Michael Shigorin wrote:
> On Mon, Nov 26, 2007 at 12:16:32AM +0300, Dmitry V. Levin wrote:
> > > > Ещё раз обратите внимание,
> > > > $ fgrep -l 'will always overflow destination buffer' *
> > > > mgetty-1.1.31-alt1.1
> > > Ну и чё с этим предлагается делать maintainerus vulgaris?
> > Орфанить я буду эти пакеты, неужели не очевидно ещё?
> 
> Почему?  Я не буду цепляться зубами за mgetty, но у нас в
> orphaned и так достаточно пакетов, которые имеют ненулевую
> ценность в том виде, в каком они есть -- если чётко обозначить, 
> что это contrib.
> 
> Дима, трамвайные колеи никогда не будут выверены до микрона.
> Стоит abort -- и пусть себе.  Достаточно.

Этого не видят те, кому следует видеть.
Другое дело, когда пакеты перестанут собираться.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Mon, Nov 26, 2007 at 12:38:31PM +0200, Michael Shigorin wrote:
> это более осмысленная работа, чем бэкпорт исправлений.
Особенно если это не те исправления, что нужны.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Я, разумеется, не имею ничего против LRN-BTS, однако базу данных для
нашей BTS по соображениям безопасности я бы хотел держать в другом месте.
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] main vs contrib, уже в который раз!

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

On Mon, Nov 26, 2007 at 03:17:12PM +0300, Dmitry V. Levin wrote:
> > > > > Ещё раз обратите внимание,
> > > > > $ fgrep -l 'will always overflow destination buffer' *
> > > > > mgetty-1.1.31-alt1.1
> > > > Ну и чё с этим предлагается делать maintainerus vulgaris?
> > > Орфанить я буду эти пакеты, неужели не очевидно ещё?
> > Почему?  Я не буду цепляться зубами за mgetty, но у нас в
> > orphaned и так достаточно пакетов, которые имеют ненулевую
> > ценность в том виде, в каком они есть -- если чётко
> > обозначить, что это contrib.
> > Дима, трамвайные колеи никогда не будут выверены до микрона.
> > Стоит abort -- и пусть себе.  Достаточно.
> Этого не видят те, кому следует видеть.
> Другое дело, когда пакеты перестанут собираться.

Дим, ещё раз предлагаю: развлекайся таким образом в main.

Оставь менее озабоченным безопасностью (вроде меня) нормальный
contrib без дракона на входе (с дракончиком и предупреждением)
и возможность _самим_ решать, брать ли на себя повышенные
обязательства или нет.  Не бери их за других, не тебе эти пакеты
суппортить.

PS: в orphaned сейчас 1385 пакетов, из них на глаз ~5% могли бы
быть полезны в составе Master (но чинить никто не будет, видимО).
Включая dfm, htmldoc, io (который вон TnL таскал в пузе, но его
чинить я тоже обломаюсь), lavaps, mnogosearch, nip, rox,
ruby-doc-extra (вообще артефакт!), sedna, tkdiff, tripwire,
wmforkplop, zoo...  Некоторые из них у меня до сих пор
установлены, но исправлять по нулевому классу -- не доберусь,
проще взять из 2.4 или 3.0.  А это плохо.

PPS: и non-free/media туда же напрашиваются, в разделение.
Долго это всё будем заставлять нарывать?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Vladimir V. Kamarzin]

>>>>> On 26 Nov 2007 at 15:28 "SS" == Slava Semushin writes:

>> > Велика вероятность, что исправлены именно эти ошибки.
>> Ну если хочешь -- пособирай.  Ноту выписывать?

 SS> Нет, спасибо. Если вдруг соберу, то положу в git, чтобы ты посмотрел и смержил.

 SS> P.S. А надо? Могу попробовать собрать новую версию (с претиркой
 SS> патчей), а, если не получится, то тогда можно попытаться сбэкпортить
 SS> фикс для этой ошибки на нашу версию. Надо?

Мне нужен mgetty, соответственно когда он перестанет собираться, придётся
чинить. Если кто-то доберётся раньше меня, буду рад и смогу
потестировать.

-- 
vvk

Re: [devel] IA: destination buffer overflow

[Vladimir V. Kamarzin]

>>>>> On 25 Nov 2007 at 17:08 "DVL" == Dmitry V Levin writes:

 DVL> xplanet-1.2.0-alt2

В orphaned.

-- 
vvk

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Tue, Nov 27, 2007 at 10:55:15AM +0500, Vladimir V. Kamarzin wrote:
>  DVL> xplanet-1.2.0-alt2
> В orphaned.

И кого таки интересуют bof'ы в этой безделушке? ;(

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] main vs contrib, уже в который раз!

[Slava Semushin]

27.11.07, Michael Shigorin<mike / osdn.org.ua> написал(а):
[...]
> PS: в orphaned сейчас 1385 пакетов, из них на глаз ~5% могли бы
> быть полезны в составе Master (но чинить никто не будет, видимО).
> Включая dfm, htmldoc, io (который вон TnL таскал в пузе, но его
> чинить я тоже обломаюсь), lavaps, mnogosearch, nip, rox,
> ruby-doc-extra (вообще артефакт!), sedna, tkdiff, tripwire,
> wmforkplop, zoo...  Некоторые из них у меня до сих пор
> установлены, но исправлять по нулевому классу -- не доберусь,
> проще взять из 2.4 или 3.0.  А это плохо.

Миш, может лучше их починить? Ты бы этот список лучше куда-нить
записАл, чтобы был рядом. Можно просто попросить любых желающих
починить пакеты из списка, можно и вовсе вознаграждение за них
пообещать, может кто-то и возьмётся.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] main vs contrib, уже в который раз!

[Michael Shigorin]

On Tue, Nov 27, 2007 at 02:53:12PM +0600, Slava Semushin wrote:
> > PS: в orphaned сейчас 1385 пакетов, из них на глаз ~5% могли
> > бы быть полезны в составе Master (но чинить никто не будет,
> > видимО).  Включая dfm, htmldoc, io (который вон TnL таскал в
> > пузе, но его чинить я тоже обломаюсь), lavaps, mnogosearch,
> > nip, rox, ruby-doc-extra (вообще артефакт!), sedna, tkdiff,
> > tripwire, wmforkplop, zoo...  Некоторые из них у меня до сих
> > пор установлены, но исправлять по нулевому классу -- не
> > доберусь, проще взять из 2.4 или 3.0.  А это плохо.
> Миш, может лучше их починить? Ты бы этот список лучше куда-нить
> записАл, чтобы был рядом.

Вот, записал.  Просто практика составления ~/TODO на починку
подобных пакетов показывает, что они покрываются толстым слоем
пыли, а чинится то, что оказывается нужно не на localhost, а для
сборки.

И то я кому-то уже numlock раздавал из загашника, поскольку он
работает, просто упал в orphaned.

> Можно просто попросить любых желающих починить пакеты из
> списка, можно и вовсе вознаграждение за них пообещать, может
> кто-то и возьмётся.

Я иногда обещаю вознаграждение за то, что мне нужно, но что не
успеваю и предпочитаю напрячь к сроку кого ещё.  Это бывает реже,
чем когда мне просто что-то нужно.

Вот, например, wmforkplop сейчас дома запущен, но из inbox письмо
с диагностикой облома выброшено -- поскольку оно там несколько
месяцев провисело и стало ясно, что этого недостаточно.

Ты не понял основную мысль: не все пакеты равны, и не ко всем
пакетам надо один ГОСТ применять.  Иначе мы рискуем оказаться 
с очень качественными танками, но почти без кастрюлек.

Историю помогает не только помнить, но и применять...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Slava Semushin]

27.11.07, Andrey Rahmatullin<wrar-alt / mail.ru> написал(а):

/* %$!@#! */

> On Mon, Nov 26, 2007 at 12:38:31PM +0200, Michael Shigorin wrote:
> > это более осмысленная работа, чем бэкпорт исправлений.
> Особенно если это не те исправления, что нужны.

Обоснуй! (с) wrar@

[...]


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Damir Shayhutdinov]

> > On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
> > > Ещё раз обратите внимание,
> > > $ fgrep -l 'will always overflow destination buffer' *
> > > mgetty-1.1.31-alt1.1
> >
> > Ну и чё с этим предлагается делать maintainerus vulgaris?
>
> Орфанить я буду эти пакеты, неужели не очевидно ещё?

Хочу обратить внимание, что эта функция еще недостаточно совершенна,
чтобы орфанить из-за нее, не разобравшись.

Я вчера наблюдал пример ложного срабатывания, которое пришлось
залечить вот таким вот патчем:

http://git.altlinux.org/people/damir/packages/?p=freedroidrpg.git;a=blob;f=freedroidrpg-0.10.3-alt-fix-buffer-overflow.patch;h=3cf47e900b1368bdbfde78c5722c8dc2c9b7b123;hb=778a38a4dd43d61abd87e07946937c9de6a8a8a9

Ложное срабатывание было в freedroidrpg/src/network.c:654

Формулировка компилятора была однозначна - always overflow. На самом
деле, до тех пор пока 0 <= PlayerNum < MAX_PLAYERS (а это именно так
при всех вызовах этой функции), никакого overflow не будет.

Пришлось добавлять лишний guard, чтобы умилостивить компилятор.

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Tue, Nov 27, 2007 at 01:11:10PM +0300, Damir Shayhutdinov wrote:
[...]
> Я вчера наблюдал пример ложного срабатывания, которое пришлось
> залечить вот таким вот патчем:
> 
> http://git.altlinux.org/people/damir/packages/?p=freedroidrpg.git;a=blob;f=freedroidrpg-0.10.3-alt-fix-buffer-overflow.patch;h=3cf47e900b1368bdbfde78c5722c8dc2c9b7b123;hb=778a38a4dd43d61abd87e07946937c9de6a8a8a9
> 
> Ложное срабатывание было в freedroidrpg/src/network.c:654
> 
> Формулировка компилятора была однозначна - always overflow. На самом
> деле, до тех пор пока 0 <= PlayerNum < MAX_PLAYERS (а это именно так
> при всех вызовах этой функции), никакого overflow не будет.
> 
> Пришлось добавлять лишний guard, чтобы умилостивить компилятор.

Этот кусок кода можно упростить до

extern struct { char a; } from[1], to[1];
void copy(int n)
{
	if (n != 0)
		memcpy(&to[1], &from[0], sizeof(to[1]));
}

Компилятор однозначно говорит: will always overflow destination buffer
Он прав, если случится n != 0, то будет выполнен код, который всегда
приводит к overflow.  Если n всегда 0, то этот вредоносный код не
выполнится никогда, и его можно убрать вместе с проверкой n != 0.

В вашем случае предупреждение компилятора пропадёт, как только MAX_PLAYERS
станет больше 1.

Добавенная вами проверка -- это не лишний guard, благодаря ней
компилятор выкинул весь цикл.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

On Tue, Nov 27, 2007 at 10:02:53AM +0200, Michael Shigorin wrote:
> On Tue, Nov 27, 2007 at 10:55:15AM +0500, Vladimir V. Kamarzin wrote:
> >  DVL> xplanet-1.2.0-alt2
> > В orphaned.
> 
> И кого таки интересуют bof'ы в этой безделушке? ;(

Похоже, что и сами эти безделушки никого не интересуют...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Michael Shigorin]

On Tue, Nov 27, 2007 at 05:14:01PM +0300, Dmitry V. Levin wrote:
> > >  DVL> xplanet-1.2.0-alt2
> > > В orphaned.
> > И кого таки интересуют bof'ы в этой безделушке? ;(
> Похоже, что и сами эти безделушки никого не интересуют...

В контексте вылизывания -- дык.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] IA: destination buffer overflow

[Damir Shayhutdinov]

> Этот кусок кода можно упростить до
>
> extern struct { char a; } from[1], to[1];
> void copy(int n)
> {
>         if (n != 0)
>                 memcpy(&to[1], &from[0], sizeof(to[1]));
> }
>
> Компилятор однозначно говорит: will always overflow destination buffer
> Он прав, если случится n != 0, то будет выполнен код, который всегда
> приводит к overflow.  Если n всегда 0, то этот вредоносный код не
> выполнится никогда, и его можно убрать вместе с проверкой n != 0.
>
> В вашем случае предупреждение компилятора пропадёт, как только MAX_PLAYERS
> станет больше 1.
Да, но проблема в том что это символ препроцессора, и насколько я
понимаю, авторы в будущем поменяют его значение. Сам по себе код
вполне правомочен, если бы компилятор не знал, что MAX_PLAYERS = 1.
Авторы писали код так, чтобы он не зависел от значения MAX_PLAYERS.

А в итоге получается что компилятор из-за оптимизации запаниковал на
ровном месте. Формально он конечно прав, а практически - нет. Это я и
считаю несовершенством проверки.

Из-за него к каждому предупреждению компилятора приходится подходить
индивидуально. Обидно также то, что апстриму необходимость guard-а
будет сложно объяснить.

> Добавенная вами проверка -- это не лишний guard, благодаря ней
> компилятор выкинул весь цикл.

Ну да, если основываться на предположении что MAX_PLAYERS будет всегда равно 1.

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

On Tue, Nov 27, 2007 at 05:25:22PM +0300, Damir Shayhutdinov wrote:
> > Этот кусок кода можно упростить до
> >
> > extern struct { char a; } from[1], to[1];
> > void copy(int n)
> > {
> >         if (n != 0)
> >                 memcpy(&to[1], &from[0], sizeof(to[1]));
> > }
> >
> > Компилятор однозначно говорит: will always overflow destination buffer
> > Он прав, если случится n != 0, то будет выполнен код, который всегда
> > приводит к overflow.  Если n всегда 0, то этот вредоносный код не
> > выполнится никогда, и его можно убрать вместе с проверкой n != 0.
> >
> > В вашем случае предупреждение компилятора пропадёт, как только MAX_PLAYERS
> > станет больше 1.
> Да, но проблема в том что это символ препроцессора, и насколько я
> понимаю, авторы в будущем поменяют его значение. Сам по себе код
> вполне правомочен, если бы компилятор не знал, что MAX_PLAYERS = 1.
> Авторы писали код так, чтобы он не зависел от значения MAX_PLAYERS.
> 
> А в итоге получается что компилятор из-за оптимизации запаниковал на
> ровном месте. Формально он конечно прав, а практически - нет. Это я и
> считаю несовершенством проверки.

Он и практически прав: поскольку у функции CopyMeToNetworkMe() глобальная
линковка, нет никаких гарантий того что она будет вызвана правильно.

> Из-за него к каждому предупреждению компилятора приходится подходить
> индивидуально. Обидно также то, что апстриму необходимость guard-а
> будет сложно объяснить.

Моё объяснение может оказаться недостаточно доступно?

> > Добавенная вами проверка -- это не лишний guard, благодаря ней
> > компилятор выкинул весь цикл.
> 
> Ну да, если основываться на предположении что MAX_PLAYERS будет всегда равно 1.

Альтернативный вариант -- завернуть этот злополучный цикл в #if MAX_PLAYERS > 1.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Damir Shayhutdinov]

> > А в итоге получается что компилятор из-за оптимизации запаниковал на
> > ровном месте. Формально он конечно прав, а практически - нет. Это я и
> > считаю несовершенством проверки.
>
> Он и практически прав: поскольку у функции CopyMeToNetworkMe() глобальная
> линковка, нет никаких гарантий того что она будет вызвана правильно.
Угу. А если бы MAX_PLAYERS не было бы равно 1, компилятор бы эту
ошибку вообще пропустил.

Как и у любой проверки, у этой есть ошибки первого и второго родов.

> > Из-за него к каждому предупреждению компилятора приходится подходить
> > индивидуально. Обидно также то, что апстриму необходимость guard-а
> > будет сложно объяснить.
> Моё объяснение может оказаться недостаточно доступно?
Они скажут "а у нас никогда не бывает случая что PlayerNum >=
MAX_PLAYERS". Хотя я не пробовал еще с ними контактировать.

> Альтернативный вариант -- завернуть этот злополучный цикл в #if MAX_PLAYERS > 1.

Возможно, нагляднее и надежнее будет завернуть memcpy в if (WriteIndex
< MAX_PLAYERS), или прям в  условие цикла -

for (i=0; i < MAX_PLAYERS && WriteIndex < MAX_PLAYERS; i++)

Думаю в таком виде у патча больше шансов.

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Денис Смирнов пишет:
> On Mon, Nov 26, 2007 at 12:16:32AM +0300, Dmitry V. Levin wrote:
> 
>>> On Sun, Nov 25, 2007 at 03:08:14PM +0300, Dmitry V. Levin wrote:
>>>> Ещё раз обратите внимание,
>>>> $ fgrep -l 'will always overflow destination buffer' *
>>>> mgetty-1.1.31-alt1.1
>>> Ну и чё с этим предлагается делать maintainerus vulgaris?
> DVL> Орфанить я буду эти пакеты, неужели не очевидно ещё?
> 
> С ppp чуток подожди -- я постараюсь на этой неделе с ним разобраться.
> 
Эх, а покажу-ка я общественности, что у меня получилось для ppp и
отправлено Денису (приаттачено).
Если не трудно- как это сделать лучше?

---
WBR, jinn.

[-- Attachment #2: ppp-2.4.4-alt-fix-overflow-destination-buffer.patch --]
[-- Type: text/plain, Size: 962 bytes --]

--- ppp-2.4.4/pppd/plugins/radius/clientid.c.orig	2007-09-29 16:38:20 +0400
+++ ppp-2.4.4/pppd/plugins/radius/clientid.c	2007-11-27 09:08:24 +0300
@@ -104,18 +104,29 @@
 UINT4 rc_map2id(char *name)
 {
 	struct map2id_s *p;
-	char ttyname[PATH_MAX];
+	char *ttyname;
+	int ttyname_len=0;
+	char prefix_dev[6];
 
-	*ttyname = '\0';
-	if (*name != '/')
-		strcpy(ttyname, "/dev/");
-
-	strncat(ttyname, name, sizeof(ttyname));
+	*prefix_dev = "";
+	ttyname_len = strlen(name)+1;
+	
+	if (*name != '/') {
+		*prefix_dev = "/dev/";
+		ttyname_len = ttyname_len+strlen(prefix_dev);
+			}
+	
+	ttyname = calloc(ttyname_len, sizeof(char));
+	snprintf(ttyname, ttyname_len, "%s%s", prefix_dev, name);
 
 	for(p = map2id_list; p; p = p->next)
-		if (!strcmp(ttyname, p->name)) return p->id;
+		if (!strcmp(ttyname, p->name)) {
+			free(ttyname);
+			return p->id;
+				}
 
 	warn("rc_map2id: can't find tty %s in map database", ttyname);
 
+	free(ttyname);
 	return 0;
 }

Re: [devel] IA: destination buffer overflow - ppp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> -	strncat(ttyname, name, sizeof(ttyname));

Автор этого кода не справился с функцией strncat.
Исправление тривиально.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Damir Shayhutdinov]

> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> > -     strncat(ttyname, name, sizeof(ttyname));
>
> Автор этого кода не справился с функцией strncat.
> Исправление тривиально.

Угу, в идеале - в одну букву - strlcat :)

Re: [devel] IA: destination buffer overflow

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Tue, Nov 27, 2007 at 03:51:45PM +0600, Slava Semushin wrote:
> > > это более осмысленная работа, чем бэкпорт исправлений.
> > Особенно если это не те исправления, что нужны.
> Обоснуй! (с) wrar@
Ну ты же нужность этих изменений вывел только из чейнджлога.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<Lost> ел сегодня тушеного кролика  с картошкой
<|Drool|> Lost: Картошка была снаружи кролика, или он ее предварительно принял
          внутрь?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Slava Semushin]

2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> > -     strncat(ttyname, name, sizeof(ttyname));

+ strncat(ttyname, name, sizeof(ttyname)-1);

> Автор этого кода не справился с функцией strncat.
> Исправление тривиально.

Фикс должен быть таким (см. выше)? Или нет?

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Slava Semushin пишет:
> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
>>> -     strncat(ttyname, name, sizeof(ttyname));
> 
> + strncat(ttyname, name, sizeof(ttyname)-1);
> 
>> Автор этого кода не справился с функцией strncat.
>> Исправление тривиально.
> 
> Фикс должен быть таким (см. выше)? Или нет?
> 
Вот так собралось без warning'а (аттач).

---
WBR, jinn.



[-- Attachment #2: ppp-2.4.4-alt-fix-overflow-buffer.patch --]
[-- Type: text/plain, Size: 391 bytes --]

--- ppp-2.4.4/pppd/plugins/radius/clientid.c.orig	2007-09-29 16:38:20 +0400
+++ ppp-2.4.4/pppd/plugins/radius/clientid.c	2007-11-28 11:46:33 +0300
@@ -110,7 +110,7 @@
 	if (*name != '/')
 		strcpy(ttyname, "/dev/");
 
-	strncat(ttyname, name, sizeof(ttyname));
+	strncat(ttyname, name, sizeof(name));
 
 	for(p = map2id_list; p; p = p->next)
 		if (!strcmp(ttyname, p->name)) return p->id;

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Wed, Nov 28, 2007 at 11:55:09AM +0300, Dmitriy Khanzhin wrote:
> Вот так собралось без warning'а (аттач).

Не трогайте чего Вы не понимаете, а то сломаете ppp и он у всех будет
глючить!  Там "char *name" и sizeof его это просто размер указателя,
то есть в данном случае это не имеет никакого смысла.


> --- ppp-2.4.4/pppd/plugins/radius/clientid.c.orig	2007-09-29 16:38:20 +0400
> +++ ppp-2.4.4/pppd/plugins/radius/clientid.c	2007-11-28 11:46:33 +0300
> @@ -110,7 +110,7 @@
>  	if (*name != '/')
>  		strcpy(ttyname, "/dev/");
>  
> -	strncat(ttyname, name, sizeof(ttyname));
> +	strncat(ttyname, name, sizeof(name));
>  
>  	for(p = map2id_list; p; p = p->next)
>  		if (!strcmp(ttyname, p->name)) return p->id;

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Alexey Tourbin пишет:
> On Wed, Nov 28, 2007 at 11:55:09AM +0300, Dmitriy Khanzhin wrote:
>> Вот так собралось без warning'а (аттач).
> 
> Не трогайте чего Вы не понимаете, а то сломаете ppp и он у всех будет

Вот я и хочу понять!
А глючить "у всех" он не будет, не мой пакет, но я в нем заинтересован.

> глючить!  Там "char *name" и sizeof его это просто размер указателя,
> то есть в данном случае это не имеет никакого смысла.
> 
Спасибо!

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Slava Semushin]

28.11.07, Alexey Tourbin<at / altlinux.ru> написал(а):
> On Wed, Nov 28, 2007 at 11:55:09AM +0300, Dmitriy Khanzhin wrote:
> > Вот так собралось без warning'а (аттач).
>
> Не трогайте чего Вы не понимаете, а то сломаете ppp и он у всех будет
> глючить!

Господа, вы чего все^W такие нервные? Никто ничего не трогает. Мы
ищем/предлагем/пробуем найти решение. Без практики, ошибок, поправок
со стороны знающих почти невозможно чему-нибудь научиться, одно дело
читать, другое дело исправлять чужой код. Так что я надеюсь, что те
кто достаточно опытен помогут нам, имеющим желание помочь, но не
имеющими достаточно опыта/знаний. Ну или тогда делайте сами эти патчи,
правильные патчи, прикладывайте и всё. Но здесь, вроде бы devel@ и
разработчики собрались с самой разной квалификацией в самых разных
вопросах/областях. Давайте, уже жить дружно или, если знаете, но не
хотите помогать, так лучше и промолчите.

> Там "char *name" и sizeof его это просто размер указателя,
> то есть в данном случае это не имеет никакого смысла.

Спасибо за разъяснение.

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow - ppp

[Alexander Bokovoy]

Dmitriy Khanzhin пишет:
> Slava Semushin пишет:
>> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
>>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
>>> 
>>>> -     strncat(ttyname, name, sizeof(ttyname));
>> + strncat(ttyname, name, sizeof(ttyname)-1);
>> 
>>> Автор этого кода не справился с функцией strncat. Исправление
>>> тривиально.
>> Фикс должен быть таким (см. выше)? Или нет?
>> 
> Вот так собралось без warning'а (аттач).
Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
и равны размеру указателя, но никак не размеру строки. Там нужно
использовать strlen(ttyname).
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Dmitriy Khanzhin пишет:
> Alexey Tourbin пишет:
>> On Wed, Nov 28, 2007 at 11:55:09AM +0300, Dmitriy Khanzhin wrote:
>>> Вот так собралось без warning'а (аттач).
>> Не трогайте чего Вы не понимаете, а то сломаете ppp и он у всех будет
> 
> Вот я и хочу понять!
> А глючить "у всех" он не будет, не мой пакет, но я в нем заинтересован.
> 
>> глючить!  Там "char *name" и sizeof его это просто размер указателя,
>> то есть в данном случае это не имеет никакого смысла.
>>
> Спасибо!
> 
Получилось, как вчера писал Дамир, собрать так.

-       strncat(ttyname, name, sizeof(ttyname));
+       strlcat(ttyname, name, sizeof(ttyname));

Придется вдумчиво курить, в чем разница.

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Wed, Nov 28, 2007 at 12:35:52PM +0300, Alexander Bokovoy wrote:
> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> и равны размеру указателя, но никак не размеру строки. Там нужно
> использовать strlen(ttyname).

UINT4 rc_map2id(char *name)
{               
        struct map2id_s *p;
        char ttyname[PATH_MAX];

        *ttyname = '\0';
        if (*name != '/')
                strcpy(ttyname, "/dev/");
        
        strncat(ttyname, name, sizeof(ttyname));
                
        for(p = map2id_list; p; p = p->next)
                if (!strcmp(ttyname, p->name)) return p->id;
                
        warn("rc_map2id: can't find tty %s in map database", ttyname);
                
        return 0;                                                                                                           
}                                                                                                                            

Есть любители кодить на язычке Си всякие прикладные вещи.
И там это ещё называется "качество кода" или как-то так.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Wed, Nov 28, 2007 at 03:32:32PM +0600, Slava Semushin wrote:
> Господа, вы чего все^W такие нервные? Никто ничего не трогает. Мы
> ищем/предлагем/пробуем найти решение. Без практики, ошибок, поправок

Ну-ну.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Alexander Bokovoy пишет:
> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> и равны размеру указателя, но никак не размеру строки. Там нужно
> использовать strlen(ttyname).

А не strlen(name)?

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Wed, Nov 28, 2007 at 12:57:38PM +0300, Dmitriy Khanzhin wrote:
> Alexander Bokovoy пишет:
> > Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> > плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> > и равны размеру указателя, но никак не размеру строки. Там нужно
> > использовать strlen(ttyname).
> 
> А не strlen(name)?

Цирк какой-то.  Вы что сделать-то хотите?  Чтобы gcc не выдавал warning?
Короче лучше используйте snprintf, там ошибиться сложнее что к чему.

Но snprintf это интерпретатор, теряется ЭФФЕККТИВНОСТЬ КОДА!!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On [Wed, 28.11.2007 12:35], Alexander Bokovoy wrote:
> Dmitriy Khanzhin пишет:
> > Slava Semushin пишет:
> >> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> >>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> >>> 
> >>>> -     strncat(ttyname, name, sizeof(ttyname));
> >> + strncat(ttyname, name, sizeof(ttyname)-1);
> >> 
> >>> Автор этого кода не справился с функцией strncat. Исправление
> >>> тривиально.
> >> Фикс должен быть таким (см. выше)? Или нет?
> >> 
> > Вот так собралось без warning'а (аттач).
> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> и равны размеру указателя, но никак не размеру строки. Там нужно
> использовать strlen(ttyname).

Если ttyname объявлен как
char ttyname[PATH_MAX];
то sizeof(ttyname) будет равен PATH_MAX;

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Led]

В сообщении от Wednesday 28 November 2007 11:35:52 Alexander Bokovoy 
написал(а):
> Dmitriy Khanzhin пишет:
> > Slava Semushin пишет:
> >> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> >>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> >>>> -     strncat(ttyname, name, sizeof(ttyname));
> >>
> >> + strncat(ttyname, name, sizeof(ttyname)-1);
> >>
> >>> Автор этого кода не справился с функцией strncat. Исправление
> >>> тривиально.
> >>
> >> Фикс должен быть таким (см. выше)? Или нет?
> >
> > Вот так собралось без warning'а (аттач).
>
> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> и равны размеру указателя, но никак не размеру строки. Там нужно
> использовать strlen(ttyname).

Угу, этим вы замените бред на тавтологию:)

-- 
Led

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Alexey Tourbin пишет:
> On Wed, Nov 28, 2007 at 12:57:38PM +0300, Dmitriy Khanzhin wrote:
> Вы что сделать-то хотите?  Чтобы gcc не выдавал warning?

Я хочу понять, как оно работает, и сделать, чтобы не было warning'а и
что-бы работало.

> Короче лучше используйте snprintf, там ошибиться сложнее что к чему.
> 
> Но snprintf это интерпретатор, теряется ЭФФЕККТИВНОСТЬ КОДА!!
> 
Патч с применением snprintf я показывал вчера
http://lists.altlinux.org/pipermail/devel/attachments/20071127/72869196/attachment.ksh

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 6420 bytes --]

On Wed, Nov 28, 2007 at 01:21:42PM +0300, Dmitriy Khanzhin wrote:
> Alexey Tourbin пишет:
> > On Wed, Nov 28, 2007 at 12:57:38PM +0300, Dmitriy Khanzhin wrote:
> > Вы что сделать-то хотите?  Чтобы gcc не выдавал warning?
> 
> Я хочу понять, как оно работает, и сделать, чтобы не было warning'а и
> что-бы работало.

Вы не рубите.  Почитайте книжку называется "Си" авторы Керниган и Ритчи.

> > Короче лучше используйте snprintf, там ошибиться сложнее что к чему.
> > 
> > Но snprintf это интерпретатор, теряется ЭФФЕККТИВНОСТЬ КОДА!!
> > 
> Патч с применением snprintf я показывал вчера
> http://lists.altlinux.org/pipermail/devel/attachments/20071127/72869196/attachment.ksh

> --- ppp-2.4.4/pppd/plugins/radius/clientid.c.orig       2007-09-29 16:38:20 +0400                                                            
> +++ ppp-2.4.4/pppd/plugins/radius/clientid.c    2007-11-27 09:08:24 +0300                                                                    
> @@ -104,18 +104,29 @@                                                                                                                        
>  UINT4 rc_map2id(char *name)                                                                                                                 
>  {                                                                                                                                           
>         struct map2id_s *p;                                                                                                                  
> -       char ttyname[PATH_MAX];                                                                                                              
> +       char *ttyname;                                                                                                                       
> +       int ttyname_len=0;                                                                                                                   
> +       char prefix_dev[6];                                                                                                                  
>                                                                                                                                              
> -       *ttyname = '\0';                                                                                                                     
> -       if (*name != '/')                                                                                                                    
> -               strcpy(ttyname, "/dev/");                                                                                                    
> -                                                                                                                                            
> -       strncat(ttyname, name, sizeof(ttyname));                                                                                             
> +       *prefix_dev = "";                                                                                                                    
> +       ttyname_len = strlen(name)+1;                                                                                                        
> +                                                                                                                                            
> +       if (*name != '/') {                                                                                                                  
> +               *prefix_dev = "/dev/";                                                                                                       

Не беритесь, не беритесь, не беритесь за то чего Вы не понимаете.

> +               ttyname_len = ttyname_len+strlen(prefix_dev);                                                                                
> +                       }                                                                                                                    
> +                                                                                                                                            
> +       ttyname = calloc(ttyname_len, sizeof(char));                                                                                         
> +       snprintf(ttyname, ttyname_len, "%s%s", prefix_dev, name);                                                                            
>                                                                                                                                              
>         for(p = map2id_list; p; p = p->next)                                                                                                 
> -               if (!strcmp(ttyname, p->name)) return p->id;                                                                                 
> +               if (!strcmp(ttyname, p->name)) {                                                                                             
> +                       free(ttyname);                                                                                                       
> +                       return p->id;                                                                                                        
> +                               }                                                                                                            
>                                                                                                                                              
>         warn("rc_map2id: can't find tty %s in map database", ttyname);                                                                       
>                                                                                                                                              
> +       free(ttyname);                                                                                                                       
>         return 0;                                                                                                                            
>  }                                                                                                                                           

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow

[Epiphanov Sergei]

В сообщении от Sunday 25 November 2007 15:08:14 Dmitry V. Levin написал(а):
> Кроме того,
> $ fgrep -l 'might overflow destination buffer' *
...
> blender-2.45-alt2

Код блендера довольно своеобразен. Попробую раскопать почему ругнулся 
компилятор. Прошу только хотя бы намекнуть, что может вызвать "overflow 
destination buffer" (хотя при запуске блендера пока не натыкался ни разу 
такую проблему). Знаю, что это может быть связано с str*, printf. Что-то 
ещё?

-- 
С уважением, Епифанов Сергей

Re: [devel] IA: destination buffer overflow - ppp

[Epiphanov Sergei]

В сообщении от Wednesday 28 November 2007 12:55:31 Alexey Tourbin написал(а):
>                 if (!strcmp(ttyname, p->name)) return p->id;

На этой строке на заткнётесь? Компилятор, думаю, снова может ругнуться.

-- 
С уважением, Епифанов Сергей

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

On Wed, Nov 28, 2007 at 01:37:22PM +0300, Epiphanov Sergei wrote:
> В сообщении от Wednesday 28 November 2007 12:55:31 Alexey Tourbin написал(а):
> >                 if (!strcmp(ttyname, p->name)) return p->id;
> На этой строке на заткнётесь? Компилятор, думаю, снова может ругнуться.

Это был оригинальный код.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Alexey Tourbin пишет:
> On Wed, Nov 28, 2007 at 01:21:42PM +0300, Dmitriy Khanzhin wrote:
>> Alexey Tourbin пишет:
>>> On Wed, Nov 28, 2007 at 12:57:38PM +0300, Dmitriy Khanzhin wrote:
>>> Вы что сделать-то хотите?  Чтобы gcc не выдавал warning?
>> Я хочу понять, как оно работает, и сделать, чтобы не было warning'а и
>> что-бы работало.
> 
> Вы не рубите.  Почитайте книжку называется "Си" авторы Керниган и Ритчи.
> 
Читаю.
> 
> Не беритесь, не беритесь, не беритесь за то чего Вы не понимаете.
> 
Не взявшись раз, нельзя понять ;-)
Все равно буду пытаться :-)

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

On Wed, Nov 28, 2007 at 12:56:56PM +0600, Slava Semushin wrote:
> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> > On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> > > -     strncat(ttyname, name, sizeof(ttyname));
> 
> + strncat(ttyname, name, sizeof(ttyname)-1);
> 
> > Автор этого кода не справился с функцией strncat.
> > Исправление тривиально.
> 
> Фикс должен быть таким (см. выше)? Или нет?

Да, таким.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Alexander Bokovoy]

Alexey Tourbin пишет:
> On Wed, Nov 28, 2007 at 12:35:52PM +0300, Alexander Bokovoy wrote:
>> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
>> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
>> и равны размеру указателя, но никак не размеру строки. Там нужно
>> использовать strlen(ttyname).
> 
> UINT4 rc_map2id(char *name)
> {               
>         struct map2id_s *p;
>         char ttyname[PATH_MAX];
> 
>         *ttyname = '\0';
>         if (*name != '/')
>                 strcpy(ttyname, "/dev/");
>         
>         strncat(ttyname, name, sizeof(ttyname));
>                 
>         for(p = map2id_list; p; p = p->next)
>                 if (!strcmp(ttyname, p->name)) return p->id;
>                 
>         warn("rc_map2id: can't find tty %s in map database", ttyname);
>                 
>         return 0;                                                                                                           
> }                                                                                                                            
> 
> Есть любители кодить на язычке Си всякие прикладные вещи.
> И там это ещё называется "качество кода" или как-то так.
Это не качество кода, это несоответствие занимаемой должности. :-)

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] IA: destination buffer overflow - ppp

[Alexander Bokovoy]

Led пишет:
> В сообщении от Wednesday 28 November 2007 11:35:52 Alexander Bokovoy 
> написал(а):
>> Dmitriy Khanzhin пишет:
>>> Slava Semushin пишет:
>>>> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
>>>>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
>>>>>> -     strncat(ttyname, name, sizeof(ttyname));
>>>> + strncat(ttyname, name, sizeof(ttyname)-1);
>>>>
>>>>> Автор этого кода не справился с функцией strncat. Исправление
>>>>> тривиально.
>>>> Фикс должен быть таким (см. выше)? Или нет?
>>> Вот так собралось без warning'а (аттач).
>> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
>> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
>> и равны размеру указателя, но никак не размеру строки. Там нужно
>> использовать strlen(ttyname).
> 
> Угу, этим вы замените бред на тавтологию:)
:-)
Смысл был скорее в указании на функцию. Впрочем, код, показанный 
Турбиным, страшен не по реализации, а по сути своей.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] IA: destination buffer overflow - ppp

[Led]

В сообщении от Wednesday 28 November 2007 13:39:25 Alexander Bokovoy 
написал(а):
> Led пишет:
> > В сообщении от Wednesday 28 November 2007 11:35:52 Alexander Bokovoy
> >
> > написал(а):
> >> Dmitriy Khanzhin пишет:
> >>> Slava Semushin пишет:
> >>>> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> >>>>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> >>>>>> -     strncat(ttyname, name, sizeof(ttyname));
> >>>>
> >>>> + strncat(ttyname, name, sizeof(ttyname)-1);
> >>>>
> >>>>> Автор этого кода не справился с функцией strncat. Исправление
> >>>>> тривиально.
> >>>>
> >>>> Фикс должен быть таким (см. выше)? Или нет?
> >>>
> >>> Вот так собралось без warning'а (аттач).
> >>
> >> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> >> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> >> и равны размеру указателя, но никак не размеру строки. Там нужно
> >> использовать strlen(ttyname).
> >
> > Угу, этим вы замените бред на тавтологию:)
> >
> :-)
>
> Смысл был скорее в указании на функцию. Впрочем, код, показанный
> Турбиным, страшен не по реализации, а по сути своей.

Смысл моего сообщения в том, что strncat со strlen в параметрах - это "масло 
маслянное":)

-- 
Led

Re: [devel] [JT] IA: destination buffer overflow - ppp

[Alexander Bokovoy]

Led пишет:

>>>>> Вот так собралось без warning'а (аттач).
>>>> Еще бы оно работало. Вы же просто повторили ерунду за авторами
>>>> этого плагина. sizeof(ttyname), как и sizeof(name), равносильны
>>>> sizeof(char *) и равны размеру указателя, но никак не размеру
>>>> строки. Там нужно использовать strlen(ttyname).
>>> Угу, этим вы замените бред на тавтологию:)
>>> 
>> :-)
>> 
>> Смысл был скорее в указании на функцию. Впрочем, код, показанный 
>> Турбиным, страшен не по реализации, а по сути своей.
> 
> Смысл моего сообщения в том, что strncat со strlen в параметрах - это
> "масло маслянное":)
Это понятно, писать о том же еще раз -- как раз масло маслянное. :-)

Давайте закончим эту тему (ppp/radius). В ней уже все ясно и понятно. К
сожалению, при сборке пакетов на С/C++ от мейнтейнеров не требуется
знание языка, на котором написана программа, которую они упаковывают.
Однако рекомендацию такую я бы все же предложил включить в описание
задач и обязанностей мейнтейнеров. Для прозрачного намека на
необходимость самосовершенствования всю жизнь.

:-)
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] IA: destination buffer overflow - ppp

[Damir Shayhutdinov]

> > 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> > > On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> > > > -     strncat(ttyname, name, sizeof(ttyname));
> >
> > + strncat(ttyname, name, sizeof(ttyname)-1);
> >
> > > Автор этого кода не справился с функцией strncat.
> > > Исправление тривиально.
> >
> > Фикс должен быть таким (см. выше)? Или нет?
>
> Да, таким.
Я честно говоря нечасто пользуюсь strncat, но разве третий параметр
означает размер буфера dest? Если верить стандарту C, он означает
максимальное количество символов из src, которое будет приклеено к
dest. Следовательно, strncat(ttyname, name, sizeof(ttyname)-1) сделает
следующее - к тому что уже имеется в ttyname, добавит еще максимум
sizeof(ttyname) - 1 байт. Явное же переполнение будет, на
strlen(ttyname) перед strncat.

Так что правильнее будет strncat(ttyname, name, sizeof(ttyname) -
strlen(ttyname) - 1, или просто
strlcat(ttyname, name, sizeof(ttyname)).

Re: [devel] IA: destination buffer overflow

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On Wed, Nov 28, 2007 at 01:34:53PM +0300, Epiphanov Sergei wrote:
> В сообщении от Sunday 25 November 2007 15:08:14 Dmitry V. Levin написал(а):
> > Кроме того,
> > $ fgrep -l 'might overflow destination buffer' *
> ...
> > blender-2.45-alt2
> 
> Код блендера довольно своеобразен. Попробую раскопать почему ругнулся 
> компилятор. Прошу только хотя бы намекнуть, что может вызвать "overflow 
> destination buffer" (хотя при запуске блендера пока не натыкался ни разу 
> такую проблему). Знаю, что это может быть связано с str*, printf. Что-то 
> ещё?

extern/qhull/src/global.c:529: warning: call to __builtin___strncat_chk might overflow destination buffer


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Grigory Batalov]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Wed, 28 Nov 2007 12:15:23 +0200
Kirill A. Shutemov wrote:

> > >>>> -     strncat(ttyname, name, sizeof(ttyname));
> > >> + strncat(ttyname, name, sizeof(ttyname)-1);
> > >>
> > >>> Автор этого кода не справился с функцией strncat. Исправление
> > >>> тривиально.
> > >> Фикс должен быть таким (см. выше)? Или нет?
> > >>
> > > Вот так собралось без warning'а (аттач).
> > Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> > плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> > и равны размеру указателя, но никак не размеру строки. Там нужно
> > использовать strlen(ttyname).
>
> Если ttyname объявлен как
> char ttyname[PATH_MAX];
> то sizeof(ttyname) будет равен PATH_MAX;

  Запишите и меня в эту партию =)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitriy Khanzhin]

Damir Shayhutdinov пишет:
>>> 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
>>>> On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
>>>>> -     strncat(ttyname, name, sizeof(ttyname));
>>> + strncat(ttyname, name, sizeof(ttyname)-1);
>>>
>>>> Автор этого кода не справился с функцией strncat.
>>>> Исправление тривиально.
>>> Фикс должен быть таким (см. выше)? Или нет?
>> Да, таким.
> Я честно говоря нечасто пользуюсь strncat, но разве третий параметр
> означает размер буфера dest? Если верить стандарту C, он означает
> максимальное количество символов из src, которое будет приклеено к
> dest. Следовательно, strncat(ttyname, name, sizeof(ttyname)-1) сделает
> следующее - к тому что уже имеется в ttyname, добавит еще максимум
> sizeof(ttyname) - 1 байт. Явное же переполнение будет, на
> strlen(ttyname) перед strncat.
> 
> Так что правильнее будет strncat(ttyname, name, sizeof(ttyname) -
> strlen(ttyname) - 1, или просто
> strlcat(ttyname, name, sizeof(ttyname)).

О как!
Огромное спасибо за подробное разъяснение.
Чес-гря, меня грызли сомнения, поэтому я тут и возникал :-) слегка.
Еще раз ВСЕМ спасибо!

-- 
Rgrds, jinn.

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

On Wed, Nov 28, 2007 at 02:37:07PM +0300, Alexander Bokovoy wrote:
> Alexey Tourbin пишет:
> > On Wed, Nov 28, 2007 at 12:35:52PM +0300, Alexander Bokovoy wrote:
> >> Еще бы оно работало. Вы же просто повторили ерунду за авторами этого
> >> плагина. sizeof(ttyname), как и sizeof(name), равносильны sizeof(char *)
> >> и равны размеру указателя, но никак не размеру строки. Там нужно
> >> использовать strlen(ttyname).
> > 
> > UINT4 rc_map2id(char *name)
> > {               
> >         struct map2id_s *p;
> >         char ttyname[PATH_MAX];
> > 
> >         *ttyname = '\0';
> >         if (*name != '/')
> >                 strcpy(ttyname, "/dev/");
> >         
> >         strncat(ttyname, name, sizeof(ttyname));
> >                 
> >         for(p = map2id_list; p; p = p->next)
> >                 if (!strcmp(ttyname, p->name)) return p->id;
> >                 
> >         warn("rc_map2id: can't find tty %s in map database", ttyname);
> >                 
> >         return 0;                                                                                                           
> > }                                                                                                                            
> > 
> > Есть любители кодить на язычке Си всякие прикладные вещи.
> > И там это ещё называется "качество кода" или как-то так.
> Это не качество кода, это несоответствие занимаемой должности. :-)

Дело в том что в язычке Си нет стандартного и эффективного способа
конкатенации двух строк.  То есть язычок Си подходит для низкоуровневого
системного программирования, но когда на нём хочется писать что-то более
прикладное, то это нужно быть в значительной степени святым человеком.
Я считаю это требование несправедливым -- людишки в среднем далеко не
святы.  Поэтому не стоит кодить на Си прикладные вещи -- даже если то
что ты пишешь это правильно, то потом кто-нибудь сделать "патч" к твоему
коду так что у тебя волосы дыбом встанут.

Язык Си нужен для _реализации_ эффективной работы со строками, для
_реализации_ грамотной стратегии автоматического управления памятью
и т.п.  Это между прочим половинчато и наблюдается в менее тривиальном
сишном коде -- например, в postfix или vsftpd есть свои мини-библиотеки
для работы со строками, а в libxml2 в базовой структуре данных
xmlExpNode имеется поле "счётчик ссылок".

Так что когда есть возможность не писать на Си, а писать на чём угодно --
на шелле, awk, перле, питоне -- стоит этой возможностью воспользоваться.
Впрочем, у меня есть и иные смутные соображения, на чём нужно писать.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Wed, Nov 28, 2007 at 06:50:15PM +0300, Dmitriy Khanzhin wrote:
> > Так что правильнее будет strncat(ttyname, name, sizeof(ttyname) -
> > strlen(ttyname) - 1, или просто
> > strlcat(ttyname, name, sizeof(ttyname)).
> 
> О как!
> Огромное спасибо за подробное разъяснение.
> Чес-гря, меня грызли сомнения, поэтому я тут и возникал :-) слегка.
> Еще раз ВСЕМ спасибо!

Не берите в голову.  Это Вам, наверное, не нужно.  Если будет насущная
потребность сцепить две строки, то используйте snprintf или asprintf --
так сложнее всего ошибиться.

К программированию эта проблема имеет очень косвенное отношение, флейм
на эту тему -- это для дураков.  Умные просто не будут писать код на Си
где есть интенсивная работа со строками (или, при суровой необходимости,
напишут "прослойку" с которой будет труднее ошибаться).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] конкатенация строк

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]

On Wed, Nov 28, 2007 at 07:35:18PM +0300, Alexey Tourbin wrote:
> > > UINT4 rc_map2id(char *name)
> > > {               
> > >         struct map2id_s *p;
> > >         char ttyname[PATH_MAX];
> > > 
> > >         *ttyname = '\0';
> > >         if (*name != '/')
> > >                 strcpy(ttyname, "/dev/");
> > >         
> > >         strncat(ttyname, name, sizeof(ttyname));
> > >                 
> > >         for(p = map2id_list; p; p = p->next)
> > >                 if (!strcmp(ttyname, p->name)) return p->id;
> > >                 
> > >         warn("rc_map2id: can't find tty %s in map database", ttyname);
> > >                 
> > >         return 0;                                                                                                           
> > > }                                                                                                                            
> > > 
> > > Есть любители кодить на язычке Си всякие прикладные вещи.
> > > И там это ещё называется "качество кода" или как-то так.
> > Это не качество кода, это несоответствие занимаемой должности. :-)
> 
> Дело в том что в язычке Си нет стандартного и эффективного способа
> конкатенации двух строк.

Простейший "стандартный" варинат -- использовать snprintf:

	char dest[PATH_MAX];
	snprintf(dest, sizeof(dest), "%s%s", s1, s2);

Тут недостаток в том, что резервируется место на стеке, которое заведомо
многократно превышает то место, которое скорее всего потребутеся.  Это
уже плохо.  PATH_MAX это кажется 4096, то есть это размер страницы
памяти в ядре.  При входе в такую функцию ядро будет "раздвигать" стек,
если он ещё недостаточно раздвинут, что, в общем, не дёшево.  Это же
может "затриггить" своп!

Но, вместе с тем, полной гарантии от "обрезания" окончания строки нет,
то есть места всё же может на хватить.

Другой полустандартный вариант -- это asprintf.

	const char *str = NULL;
	if (asprintf(&str, "%s%s", s1, s2) > 0 && str) {
		...
	} else {
		/* обломалось */
	}

asprintf внутренне вызывает malloc, а это тоже не самая дешёвая
операция, которая к тому же приводит к фрагментации памяти (к
глибсишному маллоку почему-то много претензий на эту тему).
К тому же по смыслу понятно, что malloc() не нужен для "короткоживущих"
объектов, которые существуют лишь в пределах вызова функции.  Для таких
короткоживущих объектов лучше всего подходит стек.

Нужно также заметить, что функции типа snprintf и asnprintf являются по
сути мини-инерпретаторами -- они парсят строку формата и в рантайме
побуквенно её анализируют, разгребая stdargs аргменты по мере
необходимости.  Это не самый эффективный способ конкатенации строк.

Эти мои соображения в основном касаются "эффективности" сишного кода.
То есть этот код не настолько эффективен, насколько мог бы быть.
Но инсинуации на тему эффективности сишного кода зачастую сильно
преувеличны.  Так что эти варианты, в принципе, сойдут.

У меня был реально случай, когда требуется повышенная эффективность
конкатенации строк.  Это связано с тем, что там в цикле перебирается
практически астрономическое количество всяких вариантов, по числу файлов
во всех пакетах в репозитарии.

Речь идёт о apt-0.5.15lorg2-alt-genpkglist-reqfiles.patch.
Вот мой вариант "эффективной" конкатенации строк в условиях суровой
необходимости.

+static
+bool isRequiredPath(const char *dir, const char *basename)
+{
+   char fullname[strlen(dir) + strlen(basename) + 1];
+   strcpy(fullname, dir);
+   strcat(fullname, basename);
+   if (reqfiles.find(fullname) != reqfiles.end())
+      return true;
+   return false;
+}

Здесь используется нестандартная gcc'шная фича объявления стекового
массива "переменной" или же "параметризуемой" длины.  Кажется, эта фича
есть в стандарте C99 (который gcc пока не до конца поддерживает), но тут
всё равно нужно быть очень осторожным, потому что размер массива должен
быть положительным!

В общем, когда вопрос "эффективности" кода актуален, что случается
редко, то, оказывается, проверки размеров буфера проще делать вручную
и дальше использовать "старые добрые" strcpy и strcat.

В общем-то я никому не советую использовать этот мой подход, unless,
как говорится, you really-really know what you're doing.

Общая проблема тут скорее в том что на Си всего этого лучше не делать
вообще.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] конкатенация строк

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]

On Wed, Nov 28, 2007 at 07:35:18PM +0300, Alexey Tourbin wrote:
> > > UINT4 rc_map2id(char *name)
> > > {               
> > >         struct map2id_s *p;
> > >         char ttyname[PATH_MAX];
> > > 
> > >         *ttyname = '\0';
> > >         if (*name != '/')
> > >                 strcpy(ttyname, "/dev/");
> > >         
> > >         strncat(ttyname, name, sizeof(ttyname));
> > >                 
> > >         for(p = map2id_list; p; p = p->next)
> > >                 if (!strcmp(ttyname, p->name)) return p->id;
> > >                 
> > >         warn("rc_map2id: can't find tty %s in map database", ttyname);
> > >                 
> > >         return 0;                                                                                                           
> > > }                                                                                                                            
> > > 
> > > Есть любители кодить на язычке Си всякие прикладные вещи.
> > > И там это ещё называется "качество кода" или как-то так.
> > Это не качество кода, это несоответствие занимаемой должности. :-)
> 
> Дело в том что в язычке Си нет стандартного и эффективного способа
> конкатенации двух строк.

Простейший "стандартный" варинат -- использовать snprintf:

	char dest[PATH_MAX];
	snprintf(dest, sizeof(dest), "%s%s", s1, s2);

Тут недостаток в том, что резервируется место на стеке, которое заведомо
многократно превышает то место, которое скорее всего потребутеся.  Это
уже плохо.  PATH_MAX это кажется 4096, то есть это размер страницы
памяти в ядре.  При входе в такую функцию ядро будет "раздвигать" стек,
если он ещё недостаточно раздвинут, что, в общем, не дёшево.  Это же
может "затриггить" своп!

Но, вместе с тем, полной гарантии от "обрезания" окончания строки нет,
то есть места всё же может на хватить.

Другой полустандартный вариант -- это asprintf.

	const char *str = NULL;
	if (asprintf(&str, "%s%s", s1, s2) > 0 && str) {
		...
	} else {
		/* обломалось */
	}

asprintf внутренне вызывает malloc, а это тоже не самая дешёвая
операция, которая к тому же приводит к фрагментации памяти (к
глибсишному маллоку почему-то много претензий на эту тему).
К тому же по смыслу понятно, что malloc() не нужен для "короткоживущих"
объектов, которые существуют лишь в пределах вызова функции.  Для таких
короткоживущих объектов лучше всего подходит стек.

Нужно также заметить, что функции типа snprintf и asnprintf являются по
сути мини-инерпретаторами -- они парсят строку формата и в рантайме
побуквенно её анализируют, разгребая stdargs аргменты по мере
необходимости.  Это не самый эффективный способ конкатенации строк.

Эти мои соображения в основном касаются "эффективности" сишного кода.
То есть этот код не настолько эффективен, насколько мог бы быть.
Но инсинуации на тему эффективности сишного кода зачастую сильно
преувеличны.  Так что эти варианты, в принципе, сойдут.

У меня был реально случай, когда требуется повышенная эффективность
конкатенации строк.  Это связано с тем, что там в цикле перебирается
практически астрономическое количество всяких вариантов, по числу файлов
во всех пакетах в репозитарии.

Речь идёт о apt-0.5.15lorg2-alt-genpkglist-reqfiles.patch.
Вот мой вариант "эффективной" конкатенации строк в условиях суровой
необходимости.

+static
+bool isRequiredPath(const char *dir, const char *basename)
+{
+   char fullname[strlen(dir) + strlen(basename) + 1];
+   strcpy(fullname, dir);
+   strcat(fullname, basename);
+   if (reqfiles.find(fullname) != reqfiles.end())
+      return true;
+   return false;
+}

Здесь используется нестандартная gcc'шная фича объявления стекового
массива "переменной" или же "параметризуемой" длины.  Кажется, эта фича
есть в стандарте C99 (который gcc пока не до конца поддерживает), но тут
всё равно нужно быть очень осторожным, потому что размер массива должен
быть положительным!

В общем, когда вопрос "эффективности" кода актуален, что случается
редко, то, оказывается, проверки размеров буфера проще делать вручную
и дальше использовать "старые добрые" strcpy и strcat.

В общем-то я никому не советую использовать этот мой подход, unless,
как говорится, you really-really know what you're doing.

Общая проблема тут скорее в том что на Си всего этого лучше не делать
вообще.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] конкатенация строк

[Alexander Bokovoy]

Alexey Tourbin пишет:
> В общем, когда вопрос "эффективности" кода актуален, что случается 
> редко, то, оказывается, проверки размеров буфера проще делать вручную
>  и дальше использовать "старые добрые" strcpy и strcat.
> 
> В общем-то я никому не советую использовать этот мой подход, unless, 
> как говорится, you really-really know what you're doing.
> 
> Общая проблема тут скорее в том что на Си всего этого лучше не делать
>  вообще.
Нужно написать один раз грамотно и использовать в виде библиотеки.
Есть два распространенных подхода: придумывать новый вариант или носить
исправления существующих интерфейсов, которые в некоторых системах
"сломаны". Пример первого подхода -- talloc(3) в Samba, второго --
разнообразные libroken (в Heimdal) и libreplace (в Samba4).

talloc(3) (http://talloc.samba.org/) реализует механизм работы с памятью
при помощи ведения иерархии распределенных фрагментов. Идея состоит в
том, что при работе с различными структурами данных у нас довольно часто
выделение памяти происходит в зависимости от других, ранее
распределенных структур. Фактически, в результате такого распределения у
нас образуется дерево фрагментов, связанных между собой логическими
зависимостями. talloc(3) опирается на эти зависимости и предлагает
сделать их более контроллируемыми: если структура {b} появляется в
результате создания структуры {a} и по идее должна существовать не
дольше срока жизни {a}, то почему бы их не связать друг с другом?
talloc(3) определяет, что каждый указатель на память, распределенную
средствами библиотеки, может служить "родителем" для любого другого
указателя. При уничтожении {a} произойдет автоматическое уничтожение
{b}. Если {b} представляет из себя нетерминальный тип -- структуру,
которая содержит ссылки на другие, независящие от иерархии
распределения, объекты (файловые дескрипторы или еще что), то можно
определить дополнительно деструктор, который будет вызван при
уничтожении {b}.

Такой подход дает возможность очень гибкой и ошибкоустойчивой работы со
строками, а также постоянный контроль типов и защиту от несовпадения
типов при работе со структурными элементами.

Обратной стороной является некоторое падение производительности: до 3%
процентов в общем случае при использовании glibc's malloc() в качестве
"драйвера" для talloc(3). Для специфических ситуаций вроде распределения
большого количества малых фрагментов памяти -- коротких строк,
конкатенации большого количества малых фрагментов и тому подобное, можно
  выбрать другие распределители. Например, можно использовать
распределитель, основанный на анонимной mmap-памяти, написанный Andrew
Tridgell-ом: http://samba.org/~tridge/junkcode/alloc_mmap/. Этот
распределитель снижает расход памяти в Samba4 приблизительно на 10-15%
на соединение и работает быстрее. Или можно использовать tcmalloc
(http://goog-perftools.sourceforge.net/doc/tcmalloc.html) или emeamoa
(http://code.google.com/p/ememoa/)

Но это снизу, а уровнем выше talloc(3) дает хороший уровень абстракции и
удобства работы со строками и структурами, включая отладку -- любая
такая иерархия может автоматически распечатать свою структуру.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] конкатенация строк

[led]

Wednesday, 28 November 2007 19:34:23 Alexey Tourbin написав:
> On Wed, Nov 28, 2007 at 07:35:18PM +0300, Alexey Tourbin wrote:
> > > > UINT4 rc_map2id(char *name)
> > > > {
> > > >         struct map2id_s *p;
> > > >         char ttyname[PATH_MAX];
> > > >
> > > >         *ttyname = '\0';
> > > >         if (*name != '/')
> > > >                 strcpy(ttyname, "/dev/");
> > > >
> > > >         strncat(ttyname, name, sizeof(ttyname));
> > > >
> > > >         for(p = map2id_list; p; p = p->next)
> > > >                 if (!strcmp(ttyname, p->name)) return p->id;
> > > >
> > > >         warn("rc_map2id: can't find tty %s in map database",
> > > > ttyname);
> > > >
> > > >         return 0;
> > > > }
> > > >
> > > > Есть любители кодить на язычке Си всякие прикладные вещи.
> > > > И там это ещё называется "качество кода" или как-то так.
> > >
> > > Это не качество кода, это несоответствие занимаемой должности. :-)
> >
> > Дело в том что в язычке Си нет стандартного и эффективного способа
> > конкатенации двух строк.
>
> Простейший "стандартный" варинат -- использовать snprintf:
>
> 	char dest[PATH_MAX];
> 	snprintf(dest, sizeof(dest), "%s%s", s1, s2);
>
> Тут недостаток в том, что резервируется место на стеке, которое заведомо
> многократно превышает то место, которое скорее всего потребутеся.  Это
> уже плохо.  PATH_MAX это кажется 4096, то есть это размер страницы
> памяти в ядре.  При входе в такую функцию ядро будет "раздвигать" стек,
> если он ещё недостаточно раздвинут, что, в общем, не дёшево.  Это же
> может "затриггить" своп!

А если ещё и рекурсия...

>
> Но, вместе с тем, полной гарантии от "обрезания" окончания строки нет,
> то есть места всё же может на хватить.
>
> Другой полустандартный вариант -- это asprintf.
>
> 	const char *str = NULL;
> 	if (asprintf(&str, "%s%s", s1, s2) > 0 && str) {
> 		...
> 	} else {
> 		/* обломалось */
> 	}
>
> asprintf внутренне вызывает malloc, а это тоже не самая дешёвая
> операция, которая к тому же приводит к фрагментации памяти (к
> глибсишному маллоку почему-то много претензий на эту тему).

Особенно к glibc-2.5 (кстати, эта версия ещё где-то в дистрибутивах 
используется, кроме наших?)

___
Led.

Re: [devel] фрагментация памяти

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

On [Wed, 28.11.2007 21:56], Alexander Bokovoy wrote:
> Обратной стороной является некоторое падение производительности: до 3%
> процентов в общем случае при использовании glibc's malloc() в качестве
> "драйвера" для talloc(3). Для специфических ситуаций вроде распределения
> большого количества малых фрагментов памяти -- коротких строк,
> конкатенации большого количества малых фрагментов и тому подобное, можно
>   выбрать другие распределители. Например, можно использовать
> распределитель, основанный на анонимной mmap-памяти, написанный Andrew
> Tridgell-ом: http://samba.org/~tridge/junkcode/alloc_mmap/. Этот
> распределитель снижает расход памяти в Samba4 приблизительно на 10-15%
> на соединение и работает быстрее. 

Это за счёт фрагментации? glibc'ный malloc ведь тюнить можно. Сталкнувшись
с фрагментацией на проекте, сделал mallopt(M_MMAP_THRESHOLD, 32) -- т.е.
для кусков > 32 использовать mmap для распределения. Помогло.
Единственное, что озадачивает M_MMAP_THRESHOLD равный 128k по умолчанию.
Зачем так много?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] фрагментация памяти

[Alexander Bokovoy]

Kirill A. Shutemov пишет:
> On [Wed, 28.11.2007 21:56], Alexander Bokovoy wrote:
>> Обратной стороной является некоторое падение производительности: до
>> 3% процентов в общем случае при использовании glibc's malloc() в
>> качестве "драйвера" для talloc(3). Для специфических ситуаций вроде
>> распределения большого количества малых фрагментов памяти --
>> коротких строк, конкатенации большого количества малых фрагментов и
>> тому подобное, можно выбрать другие распределители. Например, можно
>> использовать распределитель, основанный на анонимной mmap-памяти,
>> написанный Andrew Tridgell-ом:
>> http://samba.org/~tridge/junkcode/alloc_mmap/. Этот распределитель
>> снижает расход памяти в Samba4 приблизительно на 10-15% на
>> соединение и работает быстрее.
> 
> Это за счёт фрагментации? glibc'ный malloc ведь тюнить можно.
> Сталкнувшись с фрагментацией на проекте, сделал
> mallopt(M_MMAP_THRESHOLD, 32) -- т.е. для кусков > 32 использовать
> mmap для распределения. Помогло. Единственное, что озадачивает
> M_MMAP_THRESHOLD равный 128k по умолчанию. Зачем так много?
шаблоны распределения памяти могут достаточно сильно варьироваться от
программы к программе и поэтому к системному распределителю
предъявляются консервативные требования вести себя хорошо на большинстве
ситуаций.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] фрагментация памяти

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

On [Wed, 28.11.2007 23:39], Alexander Bokovoy wrote:
> Kirill A. Shutemov пишет:
> > On [Wed, 28.11.2007 21:56], Alexander Bokovoy wrote:
> >> Обратной стороной является некоторое падение производительности: до
> >> 3% процентов в общем случае при использовании glibc's malloc() в
> >> качестве "драйвера" для talloc(3). Для специфических ситуаций вроде
> >> распределения большого количества малых фрагментов памяти --
> >> коротких строк, конкатенации большого количества малых фрагментов и
> >> тому подобное, можно выбрать другие распределители. Например, можно
> >> использовать распределитель, основанный на анонимной mmap-памяти,
> >> написанный Andrew Tridgell-ом:
> >> http://samba.org/~tridge/junkcode/alloc_mmap/. Этот распределитель
> >> снижает расход памяти в Samba4 приблизительно на 10-15% на
> >> соединение и работает быстрее.
> > 
> > Это за счёт фрагментации? glibc'ный malloc ведь тюнить можно.
> > Сталкнувшись с фрагментацией на проекте, сделал
> > mallopt(M_MMAP_THRESHOLD, 32) -- т.е. для кусков > 32 использовать
> > mmap для распределения. Помогло. Единственное, что озадачивает
> > M_MMAP_THRESHOLD равный 128k по умолчанию. Зачем так много?
> шаблоны распределения памяти могут достаточно сильно варьироваться от
> программы к программе и поэтому к системному распределителю
> предъявляются консервативные требования вести себя хорошо на большинстве
> ситуаций.

Это понятно. Вот только 128k, по крайней мере на первый взгляд, кажутся
взятыми с потолка. Хотя и мои 32 тоже с потолка взяты. ;)

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Wed, Nov 28, 2007 at 04:00:59PM +0300, Damir Shayhutdinov wrote:
> > > 2007/11/27, Dmitry V. Levin <ldv@altlinux.org>:
> > > > On Tue, Nov 27, 2007 at 06:32:40PM +0300, Dmitriy Khanzhin wrote:
> > > > > -     strncat(ttyname, name, sizeof(ttyname));
> > >
> > > + strncat(ttyname, name, sizeof(ttyname)-1);
> > >
> > > > Автор этого кода не справился с функцией strncat.
> > > > Исправление тривиально.
> > >
> > > Фикс должен быть таким (см. выше)? Или нет?
> >
> > Да, таким.
> Я честно говоря нечасто пользуюсь strncat, но разве третий параметр
> означает размер буфера dest? Если верить стандарту C, он означает
> максимальное количество символов из src, которое будет приклеено к
> dest. Следовательно, strncat(ttyname, name, sizeof(ttyname)-1) сделает
> следующее - к тому что уже имеется в ttyname, добавит еще максимум
> sizeof(ttyname) - 1 байт. Явное же переполнение будет, на
> strlen(ttyname) перед strncat.

Конечно.  Общая идея такая:
- Если вы видите в коде strncat(to,from,sizeof to), то это точно ошибка,
вне зависимости от остального контекста; именно её поймал компилятор.
- Кроме того, если to[0] != '\0', то в коде strncat(to,from,sizeof to)
снова переполнение на strlen(to); чтобы это проверить, надо видеть
контекст вызова strncat.

> Так что правильнее будет strncat(ttyname, name, sizeof(ttyname) -
> strlen(ttyname) - 1, или просто
> strlcat(ttyname, name, sizeof(ttyname)).

Общее правило, наверное, такое:
- если в коде можно использовать asprintf, то использовать asprintf;
- если в коде можно использовать snprintf, то использовать snprintf;
- если в коде можно использовать strlcat, то использовать strlcat;
- иначе использовать strncat;
Хотя бывают и исключения.

В данном конкретном случае: код ppp не использует asprintf, но использует
strlcat, поэтому наиболее подходящим для upstream'а изменением будет
заменить strncat на strlcat.

P.S. Не забудьте осчастливить upstream патчем.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] конкатенация строк

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Wed, Nov 28, 2007 at 08:34:23PM +0300, Alexey Tourbin wrote:
> Простейший "стандартный" варинат -- использовать snprintf:
> 
> 	char dest[PATH_MAX];
> 	snprintf(dest, sizeof(dest), "%s%s", s1, s2);
> 
> Тут недостаток в том, что резервируется место на стеке, которое заведомо
> многократно превышает то место, которое скорее всего потребутеся.  Это
> уже плохо.  PATH_MAX это кажется 4096, то есть это размер страницы
> памяти в ядре.  При входе в такую функцию ядро будет "раздвигать" стек,
> если он ещё недостаточно раздвинут, что, в общем, не дёшево.  Это же
> может "затриггить" своп!

Господа.  Я считаю что это анекдот, если конкатенация строк может
активизировать своп.  Тем не менее, это скорее правда, чем ложь.
Я не вру.  Так что вывод простой -- не стоит писать на Си.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Tue, Nov 27, 2007 at 06:45:18PM +0300, Dmitry V. Levin wrote:

>> -	strncat(ttyname, name, sizeof(ttyname));
DVL> Автор этого кода не справился с функцией strncat.
DVL> Исправление тривиально.

Я в шоке от этого треда. Он отлично подтверждает мысль что лицензию на
право писать код на C нужно выдавать после строжайшего экзамена :)

/me пошел из принципа прочитать и переписать этот код, посоветовавшись
здесь правильный ли получился результат.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Плохомy пpогpаммеpy дpайвеpы мешают!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Wed, Nov 28, 2007 at 02:33:28PM +0300, Dmitry V. Levin wrote:

> > >> -     strncat(ttyname, name, sizeof(ttyname));
>> + strncat(ttyname, name, sizeof(ttyname)-1);
> >> Автор этого кода не справился с функцией strncat.
> >> Исправление тривиально.
>> Фикс должен быть таким (см. выше)? Или нет?
DVL> Да, таким.

Это действительно лучшее решение?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<Pilot> программы, установленные с помощью cp, нужно удалять с помощью rm

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Wed, Nov 28, 2007 at 02:33:28PM +0300, Dmitry V. Levin wrote:

> > >> -     strncat(ttyname, name, sizeof(ttyname));
>> + strncat(ttyname, name, sizeof(ttyname)-1);
> >> Автор этого кода не справился с функцией strncat.
> >> Исправление тривиально.
>> Фикс должен быть таким (см. выше)? Или нет?
DVL> Да, таким.

Правильно ли я понял, что:

strlcat(ttyname, name, sizeof(ttyname));

будет лучшим решением?

А также изменить размер ttyname с PATH_MAX на PATH_MAX + 1 (с учетом '\0'
на конце)?


-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Давайте не будем здесь LORом пахнуть.
		-- aen in docs@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Wed, Nov 28, 2007 at 11:58:26PM +0300, Dmitry V. Levin wrote:

DVL> Общее правило, наверное, такое:
DVL> - если в коде можно использовать asprintf, то использовать asprintf;
DVL> - если в коде можно использовать snprintf, то использовать snprintf;
DVL> - если в коде можно использовать strlcat, то использовать strlcat;
DVL> - иначе использовать strncat;
DVL> Хотя бывают и исключения.
DVL> В данном конкретном случае: код ppp не использует asprintf, но использует
DVL> strlcat, поэтому наиболее подходящим для upstream'а изменением будет
DVL> заменить strncat на strlcat.
DVL> P.S. Не забудьте осчастливить upstream патчем.

А в каких случаях неприменим strlcat и требуется strncat?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
[...] а фирмы -- это тоже люди
		-- mike in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Thu, Nov 29, 2007 at 09:10:59AM +0300, Денис Смирнов wrote:
> А в каких случаях неприменим strlcat и требуется strncat?
Когда его нет в системе.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Правильно, это (невозможность запустить что-либо завёрнутое в
consolehelper от рута) какая-то сложно-понимаемая особенность
consolehelper, а точнее pam. С этим будем отдельно и долго
разбираться.
		-- inger in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Здравствуйте Денис Смирнов
  В сообщении от 29 ноября 2007 Денис Смирнов написал(a):
 > On Wed, Nov 28, 2007 at 02:33:28PM +0300, Dmitry V. Levin wrote:
 > > > >> -     strncat(ttyname, name, sizeof(ttyname));
 > >>
 > >> + strncat(ttyname, name, sizeof(ttyname)-1);
 > >>
 > > >> Автор этого кода не справился с функцией strncat.
 > > >> Исправление тривиально.
 > >> Фикс должен быть таким (см. выше)? Или нет?
 > DVL> Да, таким.
 >
 >
 >
 > Правильно ли я понял, что:
 > strlcat(ttyname, name, sizeof(ttyname));
 > будет лучшим решением?
 >
 > А также изменить размер ttyname с PATH_MAX на PATH_MAX + 1 (с учетом
 > '\0'
 > на конце)?
В принципе да.

Тут ещё стоит обратить внимание на сам размер PATH_MAX.
В 90% случаях этот размер излишний. А так-как массив символов создаётся 
внутри функции, то идут излишние действия по его созданию. Возможно, 
его-бы следовало сделать глобальным (вернее указатель на строку) и 
создавать динамически по реальному размеру строки, насколько я помню 
(если не путаю), getline это позволяет, плюс можно посчитать сколько 
реально  нужно с случае, если оператор ввёл вместо /dev/ttyS0 просто 
ttyS0.
Впрочем это надо смотреть код всей программы - возможно там можно как-то 
это обойти. Как я понимаю, такие большие массивы появляются из желания 
программиста не допустить переполнения буфера при вводе строки 
оператором, так что, тут надо быть внимательным, и действия по 
переделыванию кода делать осмысленные :)

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Thu, Nov 29, 2007 at 11:27:32AM +0500, Andrey Rahmatullin wrote:

>> А в каких случаях неприменим strlcat и требуется strncat?
AR> Когда его нет в системе.

А в каких системах его нет?
Я тут обратил внимание на man, что он вообще из BSD.

В других дистрибутивах Linux этой функции может не быть в libc?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Programming is like a sex: one mistake and you have to support it for all your life...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Thu, Nov 29, 2007 at 09:28:53AM +0300, Хихин Руслан wrote:
> В 90% случаях этот размер излишний. А так-как массив символов создаётся 
> внутри функции, то идут излишние действия по его созданию.
Действие там всегда одно - esp сдвинуть.

> его-бы следовало сделать глобальным (вернее указатель на строку) и 
> создавать динамически по реальному размеру строки,
Это точно сильно дороже.


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

 * Pilot[city] is now known as Pilot
<raorn> Pilot: скакова ты горада?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Wed, Nov 28, 2007 at 07:41:34PM +0300, Alexey Tourbin wrote:
> 
> К программированию эта проблема имеет очень косвенное отношение, флейм
> на эту тему -- это для дураков.  Умные просто не будут писать код на Си
> где есть интенсивная работа со строками (или, при суровой необходимости,
> напишут "прослойку" с которой будет труднее ошибаться).

Хочу выразить свою благодарность вам за такую минилекцию. :) Спасибо.


-- 

С уважением,
Алексей Морсов
программист ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
ICQ: 196766290
www.ricom.ru
www.fondmarket.ru

ALT Linux Team Member
email: swi@altlinux.ru
web: www.altlinux.ru, www.sisyphus.ru



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On [Thu, 29.11.2007 09:41], Денис Смирнов wrote:
> On Thu, Nov 29, 2007 at 11:27:32AM +0500, Andrey Rahmatullin wrote:
> 
> >> А в каких случаях неприменим strlcat и требуется strncat?
> AR> Когда его нет в системе.
> 
> А в каких системах его нет?
> Я тут обратил внимание на man, что он вообще из BSD.
> 
> В других дистрибутивах Linux этой функции может не быть в libc?

В CentOS 4(и соответственно в RHEL) точно нет.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Thu, Nov 29, 2007 at 11:28:21AM +0200, Kirill A. Shutemov wrote:

>> А в каких системах его нет?
>> Я тут обратил внимание на man, что он вообще из BSD.
>> В других дистрибутивах Linux этой функции может не быть в libc?
KAS> В CentOS 4(и соответственно в RHEL) точно нет.

Ничего себе... Очередной раз понимаю как хорошо, что я от него держусь
подальше :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Так это был вопрос, ответ или философское размышление в двух лицах?
		-- mike in #5066

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On [Thu, 29.11.2007 14:37], Денис Смирнов wrote:
> On Thu, Nov 29, 2007 at 11:28:21AM +0200, Kirill A. Shutemov wrote:
> 
> >> А в каких системах его нет?
> >> Я тут обратил внимание на man, что он вообще из BSD.
> >> В других дистрибутивах Linux этой функции может не быть в libc?
> KAS> В CentOS 4(и соответственно в RHEL) точно нет.
> 
> Ничего себе... Очередной раз понимаю как хорошо, что я от него держусь
> подальше :)

В glibc нету strlcpy и strlcat. В нашем glibc приложен патч
glibc-2.5-obsd-alt-strlcpy-strlcat.patch

Учитывая что мэнтэйнер glibc работает в redhat, трудно ожидать в их glibc
этот патч ;)

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Thu, Nov 29, 2007 at 01:51:20PM +0200, Kirill A. Shutemov wrote:

>> Ничего себе... Очередной раз понимаю как хорошо, что я от него держусь
>> подальше :)
KAS> В glibc нету strlcpy и strlcat. В нашем glibc приложен патч
KAS> glibc-2.5-obsd-alt-strlcpy-strlcat.patch
KAS> Учитывая что мэнтэйнер glibc работает в redhat, трудно ожидать в их glibc
KAS> этот патч ;)

Мне жутко интересно что мешает мантейнеру glibc включить этот патч.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН МИКША
 Если у веревки есть один конец, значит, у нее должен быть и другой.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Slava Semushin]

29.11.07, Денис Смирнов<mithraen / altlinux.ru> написал(а):
[...]
> KAS> В glibc нету strlcpy и strlcat. В нашем glibc приложен патч
> KAS> glibc-2.5-obsd-alt-strlcpy-strlcat.patch
> KAS> Учитывая что мэнтэйнер glibc работает в redhat, трудно ожидать в их glibc
> KAS> этот патч ;)

Место его работы IMHO тут абсолютно непричем.

> Мне жутко интересно что мешает мантейнеру glibc включить этот патч.

Всё просто: он против.

Цитата с http://en.wikipedia.org/wiki/Strlcpy:

"Furthermore, some, including Ulrich Drepper, argue that strlcpy and
strlcat make truncation errors easier for a programmer to ignore and
thus can introduce more bugs than they remove;[2] consequently, these
functions have not been added to the GNU C Library."

[2] http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00060.html
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00061.html


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] IA: destination buffer overflow

[Epiphanov Sergei]

В сообщении от Wednesday 28 November 2007 16:51:17 Dmitry V. Levin 
написал(а):
> extern/qhull/src/global.c:529: warning: call to __builtin___strncat_chk
> might overflow destination buffer

Спасибо!

-- 
С уважением, Епифанов Сергей

Re: [devel] IA: destination buffer overflow - ppp

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Thu, Nov 29, 2007 at 06:06:01PM +0600, Slava Semushin wrote:

>> Мне жутко интересно что мешает мантейнеру glibc включить этот патч.
SS> Всё просто: он против.
SS> Цитата с http://en.wikipedia.org/wiki/Strlcpy:

Спасибо за ссылки. Нашел по ним много еще интересного.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Отлаживание - избавление программы от лажи!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] IA: destination buffer overflow - ppp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

On Thu, Nov 29, 2007 at 06:06:01PM +0600, Slava Semushin wrote:
> 29.11.07, Денис Смирнов<mithraen / altlinux.ru> написал(а):
> [...]
> > KAS> В glibc нету strlcpy и strlcat. В нашем glibc приложен патч
> > KAS> glibc-2.5-obsd-alt-strlcpy-strlcat.patch
> > KAS> Учитывая что мэнтэйнер glibc работает в redhat, трудно ожидать в их glibc
> > KAS> этот патч ;)
> 
> Место его работы IMHO тут абсолютно непричем.
> 
> > Мне жутко интересно что мешает мантейнеру glibc включить этот патч.
> 
> Всё просто: он против.
> 
> Цитата с http://en.wikipedia.org/wiki/Strlcpy:
> 
> "Furthermore, some, including Ulrich Drepper, argue that strlcpy and
> strlcat make truncation errors easier for a programmer to ignore and
> thus can introduce more bugs than they remove;[2] consequently, these
> functions have not been added to the GNU C Library."

Забавно то, что эта позиция не помешала ему наплодить в самом glibc
достаточно кода, неправильно использующего asprintf:

2001-12-06  Ulrich Drepper  <drepper.redhat.com>
        * libio/vasprintf.c (_IO_vasprintf): Free buffer on failure.
        * assert/assert.c: Check result of __asprintf call and don't use
        string if it failed.
        * assert/assert-perr.c: Likewise.
        * inet/rcmd.c: Likewise.
        * locale/programs/localedef.c (main): Check result of
        construct_output_path and exit if it failed.
        (construct_output_path): Check result of asprintf and mkdir calls and
        fail if they failed.
        * posix/getopt.c: Check result of __asprintf calls and fail if
        they failed.
        Patch by Dmitry V. Levin <ldv.alt-linux.org>.

2004-06-14  Andreas Schwab  <schwab.suse.de>
        * stdio-common/psignal.c (psignal): Don't use BUF when asprintf
        failed.

2004-05-07  Dmitry V. Levin  <ldv.altlinux.org>
        * argp/argp-help.c (__argp_error, __argp_failure): Check result
        of __asprintf call and don't use string if it failed.
        * stdio-common/psignal.c (psignal): Likewise.
        * locale/programs/localedef.c (more_help): Likewise.
        * resolv/res_hconf.c (arg_service_list, arg_trimdomain_list,
        arg_bool, parse_line): Check result of __asprintf calls and
        don't use string if they failed.
        * sunrpc/svc_simple.c (registerrpc, universal): Likewise.
        * elf/ldconfig.c (parse_conf_include): Check result of __asprintf
        call and exit if it failed.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] ppp *def*route patches

[Michael Shigorin]

On Tue, Nov 27, 2007 at 06:45:18PM +0300, Dmitry V. Levin wrote:
> Исправление тривиально.

Кстати о птичках (ppp-2.4.4-79 из suse factory):

* Thu Aug 23 2007 - hvogel/suse.de
- Work around pppoatm MTU problems. [#301678]
* Thu Jul 26 2007 - prusnak/suse.cz
- changed libpcap to libpcap-devel in BuildRequires
* Tue Dec 19 2006 - meissner/suse.de
- fixed strncat usage in radius plugin.
* Wed Sep 13 2006 - hvogel/suse.de
- Argh, really re-enable the patch.
* Thu Sep 07 2006 - hvogel/suse.de
- fix and reenable "replace default route" patch

Дима, можешь пересмотреть #9256 как автор
ppp-20031003-alt-cleardefaultroute.patch (#3319)?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] [JT] разработчики, майнтейнеры

[Michael Shigorin]

On Wed, Nov 28, 2007 at 03:44:42PM +0300, Alexander Bokovoy wrote:
> Давайте закончим эту тему (ppp/radius). В ней уже все ясно и
> понятно.

Правильно, пришли к ещё одной теме :}

> К сожалению, при сборке пакетов на С/C++ от мейнтейнеров не
> требуется знание языка, на котором написана программа, которую
> они упаковывают.  Однако рекомендацию такую я бы все же
> предложил включить в описание задач и обязанностей
> мейнтейнеров. Для прозрачного намека на необходимость
> самосовершенствования всю жизнь.

Саш, мне без оного знания (по существу) порой приходилось
выкладывать людям слепые сборки Samba, чтоб могли заткнуть
ваши сишные дырки.  Это при том, что у нас её майнтейнит
вроде как даже не просто матёрый сишник, а один из мажорных
upstream developers и протчая-протчая-протчая.

Намёк, думаю, тоже понятен...

-- 
Ах время, время,
tempo, tempo,
zeite, time,
Мы не считаем,
не считаем,
не считайм...

Re: [devel] ppp *def*route patches

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Sat, Dec 08, 2007 at 02:20:37PM +0200, Michael Shigorin wrote:
> On Tue, Nov 27, 2007 at 06:45:18PM +0300, Dmitry V. Levin wrote:
> > Исправление тривиально.
> 
> Кстати о птичках (ppp-2.4.4-79 из suse factory):
> 
> * Thu Aug 23 2007 - hvogel/suse.de
> - Work around pppoatm MTU problems. [#301678]
> * Thu Jul 26 2007 - prusnak/suse.cz
> - changed libpcap to libpcap-devel in BuildRequires
> * Tue Dec 19 2006 - meissner/suse.de
> - fixed strncat usage in radius plugin.
> * Wed Sep 13 2006 - hvogel/suse.de
> - Argh, really re-enable the patch.
> * Thu Sep 07 2006 - hvogel/suse.de
> - fix and reenable "replace default route" patch
> 
> Дима, можешь пересмотреть #9256 как автор
> ppp-20031003-alt-cleardefaultroute.patch (#3319)?

Пакет ppp совсем пошёл по рукам.  Я туда больше не смотрю.
Делайте с ним что хотите.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] ppp *def*route patches

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Sat, Dec 08, 2007 at 03:34:21PM +0300, Dmitry V. Levin wrote:

DVL> Пакет ppp совсем пошёл по рукам.  Я туда больше не смотрю.
DVL> Делайте с ним что хотите.

Я был бы рад отдать его в надежные руки :(
Да где-ж найти желающих... :(

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> Нафига пакету net-snmp понадобился librpm? [...]
Нафига вообще пакет net-snmp?
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики, майнтейнеры

[Alexander Bokovoy]

Michael Shigorin пишет:
> On Wed, Nov 28, 2007 at 03:44:42PM +0300, Alexander Bokovoy wrote:
>> Давайте закончим эту тему (ppp/radius). В ней уже все ясно и 
>> понятно.
> 
> Правильно, пришли к ещё одной теме :}
> 
>> К сожалению, при сборке пакетов на С/C++ от мейнтейнеров не 
>> требуется знание языка, на котором написана программа, которую они
>> упаковывают.  Однако рекомендацию такую я бы все же предложил
>> включить в описание задач и обязанностей мейнтейнеров. Для
>> прозрачного намека на необходимость самосовершенствования всю
>> жизнь.
> 
> Саш, мне без оного знания (по существу) порой приходилось выкладывать
> людям слепые сборки Samba, чтоб могли заткнуть ваши сишные дырки.
> Это при том, что у нас её майнтейнит вроде как даже не просто матёрый
> сишник, а один из мажорных upstream developers и
> протчая-протчая-протчая.
> 
> Намёк, думаю, тоже понятен...

Не понятен. Ты можешь мне указать ситуации, когда требовались сборки (с
CVE и прочим) и я их не делал, а приходилось делать тебе? Я с Samba
пытаюсь последние несколько лет быть скорее консервативным в сборках,
чем экспериментатором -- для экспериментов у меня есть совсем другие
механизмы, чем сборки в Сизиф и дистрибутивы.

Думаю, что тут не имеет смысла переходить на личности, в том числе и на
личности конкретных языков. Факт остается фактом: если кто-то берется
упаковывать программу на каком-то языке, то по меньше мере он должен
уметь читать и понимать код этой программы. Какой это язык -- вообще не
важно. Экстремизм Турбина "C и C++ -- зло" я не разделяю, средства
выбираются по задачам, а не наоборот. Но и исполнители этих задач тоже
должны подбираться соответствующим образом.

Главное тут -- самосознательность. В тот же Sisyphus никто не загоняет
ни метлой, ни тряпками. Многое оставляется на честность сборщика и его
ответственность прежде всего. Если хочется собирать конкретное
приложение, но нет пока сил разобраться в его внутренностях, возможность
попросить помощь у коллег никто не отбирал.

Например, я готов помогать с вопросами по коду на C в пакетах в Sisyphus
всем, кто обратится. За последние лет шесть, так уж сложилось, что я
также стал таким помощником и в области лицензий на свободное ПО. Не
обещаю отвечать моментально, но по мере сил помогать готов.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [JT] разработчики, майнтейнеры

[Michael Shigorin]

On Mon, Dec 10, 2007 at 12:33:54PM +0300, Alexander Bokovoy wrote:
> > Намёк, думаю, тоже понятен...
> Не понятен. Ты можешь мне указать ситуации, когда требовались
> сборки (с CVE и прочим) и я их не делал, а приходилось делать
> тебе?

Последний раз это была samba-3.0.25c, это не CVE AFAIR:
http://fly.osdn.org.ua/~mike/tmp/samba/
http://lists.altlinux.org/pipermail/community/2007-August/393497.html

Кажется, ещё раз или два подобное было, пока ты в трёх буквах
собирать ничего не мог.

Собственно, намёк не на то, что ты НегодныйМайнтейнер(TM),
а на то, что желательна и порой необходима как взаимостраховка,
так и нечто вроде junior jobs.  В том числе и по части обновлений,
как это ни смешно.

> Я с Samba пытаюсь последние несколько лет быть скорее
> консервативным в сборках, чем экспериментатором -- для
> экспериментов у меня есть совсем другие механизмы, чем сборки в
> Сизиф и дистрибутивы.

Есть ещё апдейты.  Я, собственно, о них.

> Например, я готов помогать с вопросами по коду на C в пакетах в
> Sisyphus всем, кто обратится. За последние лет шесть, так уж
> сложилось, что я также стал таким помощником и в области
> лицензий на свободное ПО. Не обещаю отвечать моментально,
> но по мере сил помогать готов.

Спасибо и за предложенную, и за многую уже оказанную помощь!

Пользуясь случаем -- благодарю и других участников команды,
которые помогли патчем, соображением или просто добрым словом.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] разработчики, майнтейнеры

[Alexander Bokovoy]

Michael Shigorin пишет:
> On Mon, Dec 10, 2007 at 12:33:54PM +0300, Alexander Bokovoy wrote:
>>> Намёк, думаю, тоже понятен...
>> Не понятен. Ты можешь мне указать ситуации, когда требовались
>> сборки (с CVE и прочим) и я их не делал, а приходилось делать
>> тебе?
> 
> Последний раз это была samba-3.0.25c, это не CVE AFAIR:
> http://fly.osdn.org.ua/~mike/tmp/samba/
> http://lists.altlinux.org/pipermail/community/2007-August/393497.html
> 
> Кажется, ещё раз или два подобное было, пока ты в трёх буквах
> собирать ничего не мог.
В ТрехБуквах я не мог собирать лишь 9 месяцев в 2004 году. :-)
С тех пор все, что нужно было, собирал. Насчет нужности несобираемого 
меня еще не убедили. :-) Сейчас вот собирается 3.0.28.

> Собственно, намёк не на то, что ты НегодныйМайнтейнер(TM),
> а на то, что желательна и порой необходима как взаимостраховка,
> так и нечто вроде junior jobs.  В том числе и по части обновлений,
> как это ни смешно.
На самом деле, у нас есть несколько человек, которые собирали Samba, 
когда надо было. И Владимир Леттиев, и Григорий Баталов, и Дмитрий 
Левин. На самом деле этого более чем достаточно. Что касается меня, то я 
никогда не был против обоснованных NMU, каковые и делались.

>> Я с Samba пытаюсь последние несколько лет быть скорее
>> консервативным в сборках, чем экспериментатором -- для
>> экспериментов у меня есть совсем другие механизмы, чем сборки в
>> Сизиф и дистрибутивы.
> 
> Есть ещё апдейты.  Я, собственно, о них.
С 4.0 пока все укладывается в бранч. Если его заморозят, будем соблюдать 
процедуры. С 3.0 я хочу увидеть полиси по поддержке 3.0: она существует?

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[devel] [JT] updates

[Michael Shigorin]

On Mon, Dec 10, 2007 at 07:47:21PM +0300, Alexander Bokovoy wrote:
> > Собственно, намёк не на то, что ты НегодныйМайнтейнер(TM), а
> > на то, что желательна и порой необходима как взаимостраховка,
> > так и нечто вроде junior jobs.  В том числе и по части
> > обновлений, как это ни смешно.
> На самом деле, у нас есть несколько человек, которые собирали
> Samba, когда надо было. И Владимир Леттиев, и Григорий Баталов,
> и Дмитрий Левин. На самом деле этого более чем достаточно. Что
> касается меня, то я никогда не был против обоснованных NMU,
> каковые и делались.

Все эти люди были или есть "в группе риска" по нагрузке.
Я как раз и пытаюсь сказать, что не всегда нужна тяжёлая
артиллерия для выпуска срочных обновлений (тем реже, чем
лучше апстрим).

Понятно, что скорость обновлений является сейчас скорее
имиджево-брендовой характеристикой, чем непосредственно
востребованной большинством пользователей деятельностью
-- но от этого не сильно легче.

> >> Я с Samba пытаюсь последние несколько лет быть скорее
> >> консервативным в сборках, чем экспериментатором -- для
> >> экспериментов у меня есть совсем другие механизмы, чем
> >> сборки в Сизиф и дистрибутивы.
> > Есть ещё апдейты.  Я, собственно, о них.
> С 4.0 пока все укладывается в бранч. Если его заморозят, будем
> соблюдать процедуры. С 3.0 я хочу увидеть полиси по поддержке
> 3.0: она существует?

/incoming/updates/3.0, и думаю -- для самбы это "последняя версия
ветки".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] разработчики, майнтейнеры

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Mon, Dec 10, 2007 at 12:33:54PM +0300, Alexander Bokovoy wrote:

AB> Думаю, что тут не имеет смысла переходить на личности, в том числе и на
AB> личности конкретных языков. Факт остается фактом: если кто-то берется
AB> упаковывать программу на каком-то языке, то по меньше мере он должен
AB> уметь читать и понимать код этой программы. Какой это язык -- вообще не
AB> важно. Экстремизм Турбина "C и C++ -- зло" я не разделяю, средства
AB> выбираются по задачам, а не наоборот. Но и исполнители этих задач тоже
AB> должны подбираться соответствующим образом.

Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в котором
нет типа string и соответствующей ему логики зло изначально.

Другое дело что для задачи "системное программирование" адекватной ему
замены попросту нет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> > >Как добиться сборки с gcc3.4?
> > select-gcc 3.4
> В hasher? Каким образом?
%set_gcc_version
		-- inger in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики , майнтейнеры

[Led]

В сообщении от Tuesday 11 December 2007 17:41:49 Денис Смирнов написал(а):
> On Mon, Dec 10, 2007 at 12:33:54PM +0300, Alexander Bokovoy wrote:
>
> AB> Думаю, что тут не имеет смысла переходить на личности, в том числе и на
> AB> личности конкретных языков. Факт остается фактом: если кто-то берется
> AB> упаковывать программу на каком-то языке, то по меньше мере он должен
> AB> уметь читать и понимать код этой программы. Какой это язык -- вообще не
> AB> важно. Экстремизм Турбина "C и C++ -- зло" я не разделяю, средства
> AB> выбираются по задачам, а не наоборот. Но и исполнители этих задач тоже
> AB> должны подбираться соответствующим образом.
>
> Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в котором
> нет типа string и соответствующей ему логики зло изначально.
>
> Другое дело что для задачи "системное программирование" адекватной ему
> замены попросту нет.

Я бы сказал, адекватноых реализаций "замены" нет:)

-- 
Led

Re: [devel] [JT] разработчики , майнтейнеры

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Tue, Dec 11, 2007 at 05:48:37PM +0200, Led wrote:

>> Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в котором
>> нет типа string и соответствующей ему логики зло изначально.
>> Другое дело что для задачи "системное программирование" адекватной ему
>> замены попросту нет.
L> Я бы сказал, адекватноых реализаций "замены" нет:)

Заменой мог бы быть C++. Но либы от него мало где есть в /lib.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Больше ошибок в программе -> богаче живёт программист.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики , майнтейнеры

[Alexander Bokovoy]

Денис Смирнов пишет:
> On Tue, Dec 11, 2007 at 05:48:37PM +0200, Led wrote:
> 
>>> Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в
>>> котором нет типа string и соответствующей ему логики зло
>>> изначально. Другое дело что для задачи "системное
>>> программирование" адекватной ему замены попросту нет.
> L> Я бы сказал, адекватноых реализаций "замены" нет:)
> 
> Заменой мог бы быть C++. Но либы от него мало где есть в /lib.
При том уровне владения языком, который наблюдается у "среднего
C++-программиста", это будет трагедия хуже "среднего C-программиста".


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [JT] разработчики , майнтейнеры

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Tue, Dec 11, 2007 at 07:29:07PM +0300, Alexander Bokovoy wrote:

>> Заменой мог бы быть C++. Но либы от него мало где есть в /lib.
AB> При том уровне владения языком, который наблюдается у "среднего
AB> C++-программиста", это будет трагедия хуже "среднего C-программиста".

Мне часто не хватает языка именно "C с плюсами". Сам C++ слишком мощный
язык, чтобы его давать в руки большинству программистов :(

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
КРЕДО ФИНГЕЙЛА
 Истина в науке. Не позволяйте фактам вводить вас в заблуждение.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики , майнтейнеры

[Alexander Bokovoy]

Денис Смирнов пишет:
> On Tue, Dec 11, 2007 at 07:29:07PM +0300, Alexander Bokovoy wrote:
> 
>>> Заменой мог бы быть C++. Но либы от него мало где есть в /lib.
> AB> При том уровне владения языком, который наблюдается у "среднего 
> AB> C++-программиста", это будет трагедия хуже "среднего
> C-программиста".
> 
> Мне часто не хватает языка именно "C с плюсами". Сам C++ слишком
> мощный язык, чтобы его давать в руки большинству программистов :(
Мы для себя (в Samba) практически дописали все, что нужно -- talloc и
libevents (в Samba4) дают почти полное ощущение 'Objective C', учитывая,
что на основе talloc Rusty Russel сделал даже нормальную обработку
исключений. Для C. :-)
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [JT] разработчики , майнтейнеры

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Tue, Dec 11, 2007 at 07:52:22PM +0300, Alexander Bokovoy wrote:

>> Мне часто не хватает языка именно "C с плюсами". Сам C++ слишком
>> мощный язык, чтобы его давать в руки большинству программистов :(
AB> Мы для себя (в Samba) практически дописали все, что нужно -- talloc и
AB> libevents (в Samba4) дают почти полное ощущение 'Objective C', учитывая,
AB> что на основе talloc Rusty Russel сделал даже нормальную обработку
AB> исключений. Для C. :-)

%-)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Плохомy пpогpаммеpy дpайвеpы мешают!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики, майнтейнеры

[Slava Semushin]

11.12.07, Денис Смирнов<mithraen / altlinux.ru> написал(а):
[...]
> Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в котором
> нет типа string и соответствующей ему логики зло изначально.

Справедливости ради всё-таки возражу: в С++ есть std::string Чем не устроил?

> Другое дело что для задачи "системное программирование" адекватной ему
> замены попросту нет.

Согласен.

P.S. Разработчиками OpenBSD язык Си не помешал написАть самую
безопасную систему. Мне думается, что язык тут хоть и важен, но и про
профессионализм разработчика тоже не стОит забывать. Серьзёные ошибки
можно допустить в программе на любом ЯП.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] [JT] разработчики, майнтейнеры

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

* Slava Semushin <slava.semushin@> [071212 11:51]:
> P.S. Разработчиками OpenBSD язык Си не помешал написАть самую
> безопасную систему.
Только давайте, пожалуйста, без фоннатизма...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] разработчики, майнтейнеры

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Wed, Dec 12, 2007 at 02:41:30PM +0600, Slava Semushin wrote:

>> Не флейма ради, и все-таки -- C/C++ это безусловное зло. Язык в котором
>> нет типа string и соответствующей ему логики зло изначально.
SS> Справедливости ради всё-таки возражу: в С++ есть std::string Чем не устроил?

Извиняюсь, в C++ есть string. Но там есть и char *.

>> Другое дело что для задачи "системное программирование" адекватной ему
>> замены попросту нет.
SS> Согласен.
SS> P.S. Разработчиками OpenBSD язык Си не помешал написАть самую
SS> безопасную систему. Мне думается, что язык тут хоть и важен, но и про
SS> профессионализм разработчика тоже не стОит забывать. Серьзёные ошибки
SS> можно допустить в программе на любом ЯП.

Вперед и с песней сделать buffer overflow на Java, там это весьма сложое
развлечение :) Или на Perl. Или на Tcl. Я бы про PHP вспомнил, да в нем
самом этих самх overflow от души :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> Но это ведь костыль!!! :(
за неимением лучшего это _персональное_ решение :)
		-- shrek in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]