в 'usage' от passkey-agent написаны только длинные параметры ('--default' и '--path'), но что есть и короткие ('-d' и '-p'), можно узнать только или из интернета, или из исходников самого passkey-agent. Как и требование, что ОБЯЗАТЕЛЬНО должен быть или ключ '-d', или адрес подключения к D-Bus. Да и про '--path' я только из исходников узнал, что это адрес программы в D-Bus, а не на диске. Ещё нет информации про '--help' или '-h'. Плюс в коде патча bluez-utils-3.9-alt-pin-exec.patch опечатка: вместо ================= + if(buffer[1]!='P' && buffer[1]!='I' && buffer[2]!='N') + { + free(buffer); + return DBUS_HANDLER_RESULT_NOT_YET_HANDLED; + } =================== должно быть как минимум ================= + if(buffer[0]!='P' || buffer[1]!='I' || buffer[2]!='N' || buffer[3]!=':') + { + free(buffer); + return DBUS_HANDLER_RESULT_NOT_YET_HANDLED; + } =================== Нет НИКАКОГО указания, что строка, получаемая от helper'а, ДОЛЖНА быть в виде PIN:1234 БЕЗ пробела между ":" и самим кодом.
*** Bug 11089 has been marked as a duplicate of this bug. ***
Присылайте патчи. Смею напомнить, что passkey-agent для упаковки вообще не предназначен.
(In reply to comment #2) > Присылайте патчи. Попробую сделать. Есть вопрос: патч к данному патчу делать или к исходному тексту? В самом патче требуемые изменения я уже прописал. > Смею напомнить, что passkey-agent для упаковки вообще не предназначен. Предназначен-не предназначен - это другой вопрос. passkey-agent реально запакован? Тогда необходимо исправить ошибки. Если уж ничего не получится и Вы выкинете passkey-agent из пакета, то и баг тоже, фактически, уйдёт.
(In reply to comment #3) > > Присылайте патчи. > Попробую сделать. Есть вопрос: патч к данному патчу делать или к исходному > тексту? В самом патче требуемые изменения я уже прописал. К исходникам. > > Смею напомнить, что passkey-agent для упаковки вообще не предназначен. > Если уж ничего не получится и Вы выкинете passkey-agent из пакета Я не собираюсь его выкидывать за то, что к нему нет документации.
Патчей на документацию не вижу. Откуда инфа про двоеточие - не понимаю. Оно всё равно игнорируется. Описывать, в каком там формате строка - вообще не задача документации к passkey- agent, т.к. он в данном виде представляет собой обёртку к старым хелперам.
Открываю заново. Насчёт двоеточия: все доступные мне файлы документации в интернете и в нашей рассылке все приводят пример такого предоставителя в виде: echo "PIN:1234" Свой патч сейчас приложу.
Created attachment 1954 [details] Откорректирорванный патч из bluez-utils-3.9-alt2 Данный патч является откорректированным патчем bluez-utils-3.9-alt-pin-exec.patch из bluez-utils-3.9-alt2.
(In reply to comment #6) > Насчёт двоеточия: все доступные мне файлы документации в > интернете и в нашей рассылке все приводят пример такого предоставителя в виде: > echo "PIN:1234" Так а всё же, нахрена проверять это двоеточие?
Если хотите, то проверку двоеточия можно удалить из патча. Но, на мой взгляд, такой пустой символ будет просто всех путать, так как всё равно passkey-agent начинает втихую брать с четвёртого символа. А пользователи могут написать: PIN1234 PIN 1234 PIN 1234 считая, что используемый пин всегда будет 1234. А на самом деле получим: 234 1234 1234 Может, лучше сказать жёстко: в виде выдавать "PIN:1234", а не просить писать его 1 (один) пробел после слова PIN? А то пойдут вопросы "а почему не два или три". Ну или писать интеллектуальный разборщик, который будет между словом "PIN" и кодовой строкой выбрасывать все пробелы. Но тогда как быть, если пользователь захочет в коде поставить пробел ВПЕРЕДИ? P.S. Кстати, в моем патче есть pclose() после чтения из буфера. Нужно ли оно?
(In reply to comment #9) > такой пустой символ будет просто всех путать, Какой пустой символ? > начинает втихую брать с четвёртого символа. А пользователи могут написать: > PIN1234 > PIN 1234 > PIN 1234 Пользователи с таким же успехом могут написать вообще что угодно. Вы же как-то догадались написать именно через двоеточие. > Может, лучше сказать жёстко: в виде выдавать "PIN:1234", а не просить писать его > 1 (один) пробел после слова PIN? А то пойдут вопросы "а почему не два или три". Сейчас вообще никто никому ничего не говорит. > P.S. Кстати, в моем патче есть pclose() после чтения из буфера. Нужно ли оно? Хотите сказать, что до вас его не было?
(In reply to comment #10) > (In reply to comment #9) > > такой пустой символ будет просто всех путать, > Какой пустой символ? Четвёртый символ. Нигде нет информации, какой он должен быть и должен ли быть вообще. > > начинает втихую брать с четвёртого символа. А пользователи могут написать: > > PIN1234 > > PIN 1234 > > PIN 1234 > Пользователи с таким же успехом могут написать вообще что угодно. > Вы же как-то догадались написать именно через двоеточие. Только когда поднял документацию в интернете (которой, кстати раз-два и обчёлся). По исходнику совсем неясно. > > Может, лучше сказать жёстко: в виде выдавать "PIN:1234", а не просить писать > его > > 1 (один) пробел после слова PIN? А то пойдут вопросы "а почему не два или > три". > Сейчас вообще никто никому ничего не говорит. А зачем ждать, когда скажут? > > P.S. Кстати, в моем патче есть pclose() после чтения из буфера. Нужно ли оно? > Хотите сказать, что до вас его не было? Нет, если Вы сравните мой вариант и начальный, то увидите, что изначально pclose стоит ПОСЛЕ проверки условия на допустимость данных, а я сделал ДО.
(In reply to comment #11) > Четвёртый символ. Нигде нет информации, какой он должен быть и должен ли быть > вообще. А о первых трёх есть где-то информация? > > Пользователи с таким же успехом могут написать вообще что угодно. > Только когда поднял документацию в интернете (которой, кстати раз-два и > обчёлся). По исходнику совсем неясно. Вы думаете, что пользователи будут читать > > > Может, лучше сказать жёстко: в виде выдавать "PIN:1234", а не просить писать > > его > > > 1 (один) пробел после слова PIN? А то пойдут вопросы "а почему не два или > > три". > > Сейчас вообще никто никому ничего не говорит. > А зачем ждать, когда скажут? Вы запутались. > Нет, если Вы сравните мой вариант и начальный, то увидите, что изначально pclose > стоит ПОСЛЕ проверки условия на допустимость данных, а я сделал ДО. Т.е. он _был_. Хотя делать его до возможного return правильнее, да.
Author: Marcel Holtmann <marcel@holtmann.org> Date: Fri Oct 3 09:11:22 2008 +0200 Remove old passkey-agent and auth-agent