이 두가지 문제는 확실히 알려야 할 것 같은데 "알림"과 "경고"는 제 경험상 어지간히 알려서도 잘 안먹히더군요.

"완전환상 플러그인"이 많이 많이 나오기를 기대합니다. ^^

회의록 참고 : http://www.tattertools.com/ko/forum/vie … php?id=447

이 의견이 최종 fix된 것은 아닙니다.. TnF 님들의 다양한 의견들이 최종적으로 합리적인 인증체계를
만들어 낼 수 있을 것 같네요.. 그런 의미에서 의견들 팍!팍! 주세요..

위와같은 레이아웃으로 아이콘화 하여 표시해주면 플러그인을 사용하고자하는 블로거님들께서 한눈에 보기
좋을것 같습니다.

위에서 언급한 내용을 다시금 얘기한것 같습니다. 1.0.6버젼이후 더 확고한 문제들이 언급될것으로 보입니다.

TnF님분들 좋은 저녁시간 되세요.:cool:

저도 가장 불안히 생각하는 것중 한가지 입니다.
어떤 플러그인을 다운 받아서 설치했는데 DB에 테이블을 생성하는걸 보고 겁이나더군요.
이거 악용만하면 데이터도 마음대로 수정하거나 파괴할 수 있겠구나 하고요.

DB modify 명령이 플러그인 자체에서 동작하는 방식은 옳지 않은 것 같습니다. 만약 DB modify가 필요하다면 해당 계정의 소유자가 DB 변경에 대하여  이해한 상태에서 "직접" 변경해야 겠지요.  그런데, 테이블 생성구문까지 허용되고 있는 것은 몰랐네요.. ^^;;

사실 태터툴즈 공식 홈피에 플러그인을 제작하여 올리시는 분들 중에
그런 악의를 가지고 공개하실 분은 거의 없겠죠... 소스까지 다 공개되는데
오픈소스 특성상 악의를 가지고 무언가를 공개하시는 분들은 극소수일거란 생각이 듭니다.

정말로 문제되는 것은 진정한 악인으로서의 의도를 가지고 공식 홈페이지가 아닌 곳에서
비공개로 배포하는 것이죠...  마치 와레즈에서 비공식으로 크랙에 바이러스를 묻히는 것처럼요... ^^;

이런 바이러스에 감염되는 건 사실상 사용자의 책임이 크다고 봅니다.

그런데 또 설치형 블로그를 사용하시는 분들 중에서는 이정도는 가려서 쓰실 능력이 충분하시다고 생각을 합니다.
그렇지 않은 분들은 Tistory 나 이노리, 오마이뉴스 블로그를 사용하지 않을까요...
당연히 서비스형 태터툴즈에서 제공되는 플러그인들은 기본적으로 검수를 거친 플러그인 들일테니까요. ^^;

하여간 참 어려운 문제네요...

물론 뉴클리어스의 경우 플러그인도 GPL이 적용돼서 누구나 기존의 플러그인을 이용해서 자신에게 맞거나 필요로 하는 플러그인을 제작합니다. 또 개발이 중단되면 다른 사람이 이걸 이어받아서 계속 개발하거나 새로운 플러그인이 기존의 플러그인을 대체하기도 하고요.

태터도 이런 자연스러운 검증절차를 두면 좋겠습니다.

개별 플러그인에 대해서 TnF certificated plugin 으로 안정성이나 보안, 버전 적합성등의 검증을 거쳐 인증을 부여하고 더불어 일종의 TnF partner 형태로 특정 제작자 그 자체의 신뢰도를 인정하여 그로부터 나오는 플러그인에 파트너 인증을 부여하는 편이 괜찮다 봅니다. 이러한 인증작업을 얼마전에 제기된 TnF 체계화와 더불어 TnF 의 역할의 하나로 자리잡아도 괜찮겠지요.

TnC 는 platform 으로서의 TT 개발에 집중하고, 플러그인이나 스킨등 application 의 측면은 TnF 가 맡는다면 업무의 무게도 어느정도 분할이 되겠지요.

플러그인을 TNF/TNC에서 검증하여 안전하다고 확인이 되면 일종의 인증 마크를 달고 배포할 수 있도록 하는 것도 좋을 것 같습니다. 현재의 제로보드 게시판 형식으로 된 플러그인 게시판을 좀더 뽀대(-_-)나게 바꾸어서(Firefox 플러그인 사이트 정도만 되어도 괜찮을 듯..;; ) 개발자들이 거기에 자신의 플러그인이 인증된 채 배포되는 걸 자랑스럽게 여기도록 유도(..)하는 것도 좋을 것 같습니다.

검증작업에 대한 TNF/TNC의 업무부하가 눈에 보입니다.. 농담이구요..

제작한 플러그인을 자유롭게 올릴 수 있는 현 체계와 검증작업을 도입한 인증체계 사이의 장단점에 대해
TNF에서 한번 논의를 해보면 어떨까 싶군요..

위 글들을 읽고 몇가지 생각해 본 배포체계를 적어봅니다..

1. 플러그인 인증체계 도입
- 개발자가 제작한 플러그인에 대해 TNF나 TNC에 인증요청을 한 후 인증이 완료되면 플러그인 게시판(사이트)에
   올려짐.. 인증이 안된 플러그인에 대해서는 내용조회만 가능..
   외부 업체들 중에서도 플러그인 인증 요청을 한 후 정식적으로 인증된 후에 배포되는 사례들이 있습니다..

2. 현행 플러그인 배포체계 + 인증체계
  - 현 체계처럼 자유롭게 제작한 플러그인을 배포할 수 있도록 합니다.. 대신 인증체계를 믹스하여 TNF/TNC에 의해
    공식적으로 인증된 플러그인에 대해서는 인증마크를 부여하여 사용자에게 플러그인의 사용에 대한 선택권한을
    넘겨줍니다..

3. 현행 플러그인 배포체계 + 사용자 레벨제 도입
  - 현행 플러그인 배포체계에 실재 플러그인을 사용해 본 유저들에 의한 평가체계(별점제 등)를 도입하여
    플러그인에 대한 안정성을 사용자들에게 판단하도록 합니다.. TNF/TNC의 업무부하를 줄일 수 있는 장점이
    있습니다.. 대신 악의적인 의도로 작성된 플러그인에 대해 사전 제약을 줄 수 없는 단점이 존재합니다..

4. 플러그인 제작자 인증체계
  - 플러그인의 제작자들에 대한 인증체계를 도입하여(오픈마켓의 셀러들에 대한 등급제같은..) 공식적으로
    인증이 된 제작자들의 플러그인은 안심하고 받아서 설치할 수 있는 체계를 도입합니다.. 인증된 제작자의
    선정에 대한 기준이 먼저 마련되어야 하고 제작자 역시 본인이 개발하여 배포하는 플러그인에 대한 책임을
    질 수 있는 환경이 조성되어야 하겠죠..

일단 플러그인을 검증하는 기술적인 내용에 대해서는 TNF 전문가분들에게 떠 넘기고.. 머리속에서
생각나는대로 한번 적어봤습니다..

관리하기 쉽게 인터페이스를 갖추는 것도 하나의 방법입니다.

표준적인 인터페이스를 통해서 플러그인의 개발자가 직접 위험 수위나 디테일한 내용을 (여기서는 DB의 수정 정도 되겠네요.) 표기하는 방법을 제시하고 사용자가 확인할 수 있게 하는 것입니다. 세부적인 방법은 여러가지가 있겠습니다만 한 가지 방법은 주석이 무조건 일정한 형태를 취하도록 하는 것입니다. 형태에 적합할 때 주석의 내용을 유저에게 표기해 주게 하고 적합하지 않을 때는 플러그인은 자동 deactivate되면 될 것입니다.

관리자는 개발자가 표기한 위험수위와 디테일한 내용을 확인하고 그것이 사실과 동일할 때만 플러그인을 공개합니다. 더 나아가 확장 등록자에 대해서 화이트 리스트나 블랙 리스트를 관리할 수도 있겠지요.

이 방법은 몇가지 이점이 있습니다.

1. 개발자가 제시한 정보가 관리자의 체크리스트가 된다.
2. 개발자가 어느정도 보안에 대해 책임을 느끼게 된다.
3. 항목과 다를 때 유저나 관리자가 따질 근거가 된다.

지금 구현된 형태가 그러한 형태입니다. index.xml에 이 플러그인의 동작 범위에 대하여 적도록 되어 있습니다.

문제는 제작자 분들이 저 목록을 항상 형식에 맞게 적어주시지 않는다는 점이죠. 결국 말씀하신대로 플러그인을 설치하는 관리자분들이 직접 체크를 하시거나, 아니면 플러그인이 올라오면 보안에 관련된 내용을 체크하는 팀을 만들거나 해야 할 것 같습니다.

표준적인 인터페이스를 통해서 플러그인의 개발자가 직접 위험 수위나 디테일한 내용을 (여기서는 DB의 수정 정도 되겠네요.) 표기하는 방법을 제시하고 사용자가 확인할 수 있게 하는 것입니다. 세부적인 방법은 여러가지가 있겠습니다만 한 가지 방법은 주석이 무조건 일정한 형태를 취하도록 하는 것입니다. 형태에 적합할 때 주석의 내용을 유저에게 표기해 주게 하고 적합하지 않을 때는 플러그인은 자동 deactivate되면 될 것입니다.

관리자는 개발자가 표기한 위험수위와 디테일한 내용을 확인하고 그것이 사실과 동일할 때만 플러그인을 공개합니다. 더 나아가 확장 등록자에 대해서 화이트 리스트나 블랙 리스트를 관리할 수도 있겠지요.

이 방법은 몇가지 이점이 있습니다.

1. 개발자가 제시한 정보가 관리자의 체크리스트가 된다.
2. 개발자가 어느정도 보안에 대해 책임을 느끼게 된다.
3. 항목과 다를 때 유저나 관리자가 따질 근거가 된다.

현재의 플러그인 제작 방식을 그대로 사용한다면야 악의적인 코드를 찾기란 무리겠죠.
BlogIcon 플러그인을 기준으로 제가 생각하는 대략적인 구상을 말해보겠습니다.

components/Tattertools.Plugins.php 파일

class Plugins {
    var $owner;
    var $database;
    ...
    function tt_empty($v) {
        return empty($v);
    }

    function tt_strlen($v) {
        return strlen($v);
    }
    ...
}

Plugins/BlogIcon/index.php

class BlogIcon extends Plugins {
    var $target;
    var $mother;

    function BlogIcon($target, $mother) {
        $this->__construct($target, $mother);
    }

    function __construct($target, $mother) {
        $this->target = $target;
        $this->mother = $mother;
    }

    function BlogIcon_main() {
        if (Plugins::tt_empty($this->mother['homepage']))
            return $this->target;
        $slash = ($this->mother['homepage']{Plugins::tt_strlen($this->mother['homepage']) - 1} == '/' ? '' : '/');
        return "<img src=\"{$this->mother['homepage']}{$slash}index.gif\" width=\"16\" height=\"16\" onerror=\"this.parentNode.removeChild(this)\"/> $this->target";
    }
}

Plugins/BlogIcon/index.xml

...
    <listener event="ViewCommenter">BlogIcon::BlogIcon_main</listener>
    <listener event="ViewGuestCommenter">BlogIcon::BlogIcon_main</listener>
...

상당히 노가다이긴 하지만..; Plugins class에 사용 가능한 함수들을 일일이 등록시켜주는 거죠.;;
(모듈화된 상태기때문에 개별적으로 업데이트가 이루어지면 되니 큰 문제는 아니라고 생각중)
이렇게되면 validate 시에 Plugins class를 거치지 않는 함수를 잡아내는건 쉽겠죠.
쿼리같은 경우는 아래처럼 대충 처리하고 drop같은건 지원을 안하면 되겠죠.;
(예전에 사용하던 MySQL class 발췌; )

function mysql_select($table, $where, $field = '*') {
    return mysql_query("SELECT ".$field." FROM ".$table." ".$where);
}

헛점이 너무 많은가요? -_-;;

이것은 인터페이스만을 제한하는 것으로, 앞서 논의된 문제 해결과 관련이 없습니다.
이렇게 하면 플러그인 개발이 더 힘들어지기 때문에 지금의 간단한 구조를 채택한 것입니다.

음.. 그냥 index.php 체크하는게 더 쉬울려나요?;

생각은 해놓고.. 내용 괜히 길어질까봐 올리지않았던 내용입니다만
user_func나 include등이 발견되면 "외부 코드 호출 발견"
fopen 같은건 "파일 입출력 발견"
exit; 같은것도 그렇고요..

진짜 플러그인이 위험한지를 검증하는걸 만들면.. 그것 자체로도 태터 이상의 프로젝트가 될것 같습니다.

components/Tattertools.Plugins.php 파일

class Plugins {
    var $owner;
    var $database;
    ...
    function tt_empty($v) {
        return empty($v);
    }

    function tt_strlen($v) {
        return strlen($v);
    }
    ...
}

Plugins/BlogIcon/index.php

class BlogIcon extends Plugins {
    var $target;
    var $mother;

    function BlogIcon($target, $mother) {
        $this->__construct($target, $mother);
    }

    function __construct($target, $mother) {
        $this->target = $target;
        $this->mother = $mother;
    }

    function BlogIcon_main() {
        if (Plugins::tt_empty($this->mother['homepage']))
            return $this->target;
        $slash = ($this->mother['homepage']{Plugins::tt_strlen($this->mother['homepage']) - 1} == '/' ? '' : '/');
        return "<img src=\"{$this->mother['homepage']}{$slash}index.gif\" width=\"16\" height=\"16\" onerror=\"this.parentNode.removeChild(this)\"/> $this->target";
    }
}

Plugins/BlogIcon/index.xml

...
    <listener event="ViewCommenter">BlogIcon::BlogIcon_main</listener>
    <listener event="ViewGuestCommenter">BlogIcon::BlogIcon_main</listener>
...

상당히 노가다이긴 하지만..; Plugins class에 사용 가능한 함수들을 일일이 등록시켜주는 거죠.;;
(모듈화된 상태기때문에 개별적으로 업데이트가 이루어지면 되니 큰 문제는 아니라고 생각중)
이렇게되면 validate 시에 Plugins class를 거치지 않는 함수를 잡아내는건 쉽겠죠.
쿼리같은 경우는 아래처럼 대충 처리하고 drop같은건 지원을 안하면 되겠죠.;
(예전에 사용하던 MySQL class 발췌; )

function mysql_select($table, $where, $field = '*') {
    return mysql_query("SELECT ".$field." FROM ".$table." ".$where);
}

헛점이 너무 많은가요? -_-;;