코틀린은 ‘젯브레인스(JetBrains)’라는 회사에서 만든 안드로이드 개발을 위한 프로그래밍 언어로, 2016년도에 정식 발표되었습니다. 코틀린은 기존에 안드로이드 어플리케이션 개발에 활용되는 자바(Java) 언어를 보완하고 대체하기 위해 탄생했는데요. 때문에기존에 자바 언어로 동작하던 환경에서 코틀린 언어도 100% 호환되는 것이 특징입니다. 이는 기존에 자바로 개발하던 프로그램은 모두 코틀린으로도 개발할 수 있다는 의미입니다.
2017년 열린 구글 I/O라는 컨퍼런스에서 코틀린은공식 지원 언어로 채택되었습니다. 공식 지원 언어로 채택이 되었다는 건 과연 어떤 의미일까요? 구글이 코틀린을 공식 지원 언어로 채택하면서, 코틀린 플러그인을 안드로이드 스튜디오(Android Studio) 3.0에서 바로 다운로드하여 이용할 수 있게 되었다는 의미입니다. 이외에도 안드로이드 공식 문서의 예제 코드도 코틀린으로 제공되는 것을 확인할 수 있습니다.
Android 개발이 Kotlin 우선인 이유
Google은 컨퍼런스, 고객 자문위원회(CAB), Google 개발자 전문가(GDE) 및 자사 개발자 연구를 통해 개발자로부터 직접 받은 의견을 검토했습니다. 많은 개발자가 이미 Kotlin을 즐겨 사용하고 있으며 Kotlin 지원 추가에 관한 요청이 분명했습니다. 개발자가 말하는 Kotlin을 사용한 코드 작성의 이점은 다음과 같습니다.
표현력이 높고 간결함:적은 노력으로 많은 작업을 할 수 있습니다. 상용구 코드를 적게 사용하면서도 아이디어를 풍부하게 표현할 수 있습니다. Kotlin을 사용하는 전문 개발자 중 67%가 Kotlin을 통해 생산성이 높아졌다고 말합니다.
더 안전한 코드:Kotlin에는 null 포인터 예외와 같은 일반적인 프로그래밍 실수를 방지하는 데 도움이 되는 여러 언어 기능이 있습니다. Kotlin 코드가 포함된 Android 앱은 다운될 가능성이 20% 낮습니다.
호환성:Kotlin에서 자바 기반 코드를 호출하거나 자바 기반 코드에서 Kotlin을 호출합니다. Kotlin은 자바 프로그래밍 언어와 100% 호환되므로 프로젝트에서 Kotlin을 원하는 만큼 사용할 수 있습니다.
구조화된 동시 실행:Kotlin 코루틴을 사용하면 비동기 코드를 차단 코드처럼 쉽게 사용할 수 있습니다. 코루틴은 네트워크 호출부터 로컬 데이터 액세스에 이르기까지 백그라운드 작업 관리를 크게 단순화합니다.
Kotlin 우선이란 무엇을 의미할까요?
Jetpack 라이브러리, 샘플, 문서, 교육 콘텐츠와 같은 새로운 Android 개발 도구와 콘텐츠를 빌드할 때 Google은 Kotline 사용자를 염두에 두고 디자인하는 동시에 자바 프로그래밍 언어에서 Google의 API를 사용할 수 있도록 지원을 계속 제공합니다.
지금 우리가 수행할 작업은 1.x 버전에서 2.x 버전으로 변경하는 작업이므로 해당 작업을 중점으로 설명하겠다.
( log4j2-2.x.x 버전 업그레이드는 라이브러리만 교체하면 되는것으로 알고 있음)
<라이브러리 교체>
프로젝트의 상황에 따라 일부 라이브러리는 차이가 있을 수 있다.
(예를 들면 remix / jdbc가 붙은 log4j 관련 라이브러리)
그러나 버전 업그레이드에 반드시 필요한 파일은 3개가 있으며 slf4j를 사용하는 경우 1개의 교체해야하는 파일이 있다.
log4j-core-2.x.x.jar
log4j-api-2.x.x.jar
log4j-web-2.x.x.jar
log4j-slf4j-impl-2.x.x.jar
추가
Slf4j 사용시 추가 ( 교체 : slf4j-log4j12-1.x.x.jar)
기존 프로젝트에 삭제되어야하는 라이브러리는 다음과 같다.
log4j-1.x.x.jar
slf4j-log4j12-1.x.x.jar (slf4j를 사용하지 않는 경우에는 해당 파일이 없을 수 있으나 대부분의 프로젝트에는 있다.)
추가되어야 하는 라이브러리
log4j-core-2.x.x.jar
log4j-api-2.x.x.jar
log4j-web-2.x.x.jar
log4j-slf4j-impl-2.x.x.jar / log4j2-2.x.x용 바인딩 파일 (slf4j를 사용하지 않는 경우 제외)
slf4j를 사용하며 기존에 존재하는 라이브러리 중 유지해야하는 라이브러리
slf4j-api-1.x.x.jar / 기존 소스에서 API를 사용하고 있으므로 삭제하지 않음
<설정 변경 : WEB.XML>
log4j2.xml 경로설정 - log4j-2.x 버전에서는 web.xml에서 경로나 파일명을 명시하지 않으면 기본값으로 classpath: 경로에서 log4j2-test.xml 또는 log4j2.xml 파일을 찾는다고 한다. (log4j 에서도 동일했던 것 같은데..)
Logback에서 발생하는 원격코드 실행 취약점 (CVE-2021-42550)[2] - 공격자가 Logback구성파일인 logback.xml을 조작할 경우, 해당파일을 참조하는 과정에서 삽입된 JNDI*쿼리문을 실행 해 임의의 원격코드를 실행할 수 있는 취약점 ※ 공격 전제조건 - Logback구성파일 logback.xml에 대한 쓰기 권한이나 해당파일을 수정/덮어쓰기 가능할 경우 - 수정된 구성파일 logback.xml을 환경에 적용(reload)할 수 있는 권한
* JNDI : 디렉토리 서비스에서 제공하는 데이터 및 객체를 발견하고 참고하기 위한 Java API (Java Naming and Directory Interface의 약어)
영향받는버전
- 1.2.8 이하 모든버전 - 1.3.0-alpha10 이하 모든버전
해결방안
취약점 업데이트 (패치 적용 前 업무시스템의 서비스 영향 검토 후 적용할 것) - 1.2.8이하 버전의 경우, 최신 버전(1.2.9) 업그레이드 적용 [3] - 1.3.0-alpha10이하 버전의 경우, 1.3.0-alpha11로 업그레이드 적용[3] ※ 1.3.x시리즈의 경우, 기본적으로 JAVA9 모듈화 되어 있으며 slf4j-api 버전 2.0.x 필요 (runtime에는 Java8이상이면 되지만, 소스에서 Logback을 빌드하려면 Java9 필요)
임시 조치방안 (패치 즉시적용 불가할 경우)
1) 구성파일 logback.xml파일의 권한을 read-only로 변경 ※ logback.xml 파일 위치 : /src/main/resources/