jacodb导入带签名的jar包失败的问题

        今天在执行某个项目分析时,100多个jar包只有BC库的三个jar包导入失败。错误如下:

[DefaultDispatcher-worker-1 @coroutine#1] INFO org.jacodb.impl.storage.PersistenceService - Starting app version [1.4]
[DefaultDispatcher-worker-16 @coroutine#150] WARN org.jacodb.impl.fs.JarLocation - error loading classes from jar: bcutil-jdk15on-1.70.jar. returning empty loader
java.lang.IllegalStateException: zip file closed
	at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:840)
	at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:369)
	at java.base/java.util.jar.JarFile.getBytes(JarFile.java:800)
	at java.base/java.util.jar.JarFile.checkForSpecialAttributes(JarFile.java:1006)
	at java.base/java.util.jar.JarFile.isMultiRelease(JarFile.java:388)
	at java.base/java.util.jar.JarFile$JarFileEntry.realEntry(JarFile.java:691)
	at java.base/java.util.jar.JarFile.verifiableEntry(JarFile.java:869)
	at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:861)
	at org.jacodb.impl.fs.JarFacade.getBytecode(Jars.kt:84)
	at org.jacodb.impl.fs.JarLocation.getClasses(JarLocationImpl.kt:48)
	at org.jacodb.impl.fs.ByteCodeLoaderImplKt.getSources(ByteCodeLoaderImpl.kt:24)
	at org.jacodb.impl.JcDatabaseImpl$process$3$1$1.invokeSuspend(JcDatabaseImpl.kt:138)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

刚开始看到这个错误,以为时多个线程同时加载class文件,之间没同不好,有线程提前关闭了文件导致的。看了读取源码实在没看懂,后续将正常可以加载的jar包对比了下,发现BC库的jar包多了签名文件,删除这几个文件就可以正常加载了。

jar包对比:

红框中的四个文件时jar包的签名文件。

这几天又看了这个问题,感觉删文件太麻烦,需要遍历所有jar包。经过多次复现该问题和翻看源代码后发现,JarFile类在加载jar包时可以选择是否验证签名。而jacodb中设置了需要验证签名,源码如下:

        具体提JarFile是怎么验证签名的代码没有再翻看,猜测是验证签名出了问题,就把读取jar包的流关闭了,而后续再读取jar包中class时,导致了zip file closed的异常。

        使用jarsigner命令验证得到如下结果

C:\Users\Desktop\bclib>jarsigner -verify -certs bcutil-jdk15on-1.70.jar

jar 已验证。

警告:
此 jar 包含其证书链无效的条目。原因: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
DSA 签名密钥的密钥大小 1024 被视为存在安全风险。此密钥大小将在未来的更新中被禁用。

有关详细信息, 请使用 -verbose 和 -certs 选项重新运行。

        感觉是证书链没验证通过导致的验证失败。目前猜想的原因是,证书链问题导致签名验证失败,验证失败导致JarFile关闭了jar包读取的流,导致读取class内容是报“zip file closed”的异常。

        后续有时间将相关的证书安装上再试下。

这个错误信息表明,在尝试向数据库插入数据时,提供的日期值 `'12830-08-01 00:00:00'` 超出了 MySQL 中 `DATETIME` 或 `TIMESTAMP` 类型的有效范围。 ### 原因分析 1. **MySQL 的有效日期范围** - 对于 `DATE`, `DATETIME`, 和 `TIMESTAMP` 数据类型,有效的日期范围通常是: ``` 1000-01-01 到 9999-12-31 (对于 DATE/DATETIME) 1970-01-01 到 2038-01-19 (对于 TIMESTAMP) ``` 提供的日期 `'12830-08-01'` 远远超出了上述范围,因此无法存储到列 `end_date` 中。 2. **输入验证不足** 如果未对用户输入或程序生成的数据进行严格的校验,则可能导致这种无效日期进入数据库操作流程。 --- ### 解决方案 #### 方法一:修正数据源中的非法日期值 检查并修改导致该问题的具体记录。例如,如果你发现某个字段被误设为未来的极端年份(如12830),可以将其调整为合理的数值(比如当前时间或其他合法值)。示例 SQL 修改命令如下: ```sql UPDATE your_table_name SET end_date = '9999-12-31' WHERE id = problematic_id; ``` #### 方法二:在应用层添加数据验证逻辑 确保所有传递给数据库的操作都经过合法性检查,避免类似超出范围的情况发生。可以在代码中加入条件判断: ```python import datetime def validate_date(date_str): try: # 尝试解析字符串为标准格式,并限制最大日期不超过指定范围 dt_obj = datetime.datetime.strptime(date_str, '%Y-%m-%d %H:%M:%S') max_allowed_date = datetime.datetime(9999, 12, 31) # 最大允许日期设置 if dt_obj > max_allowed_date or dt_obj < datetime.datetime(1900, 1, 1): # 可选最小日期设置 raise ValueError("Date out of valid range") except Exception as e: print(f"Invalid date {date_str}: {e}") return False return True # 测试函数 test_dates = ["12830-08-01 00:00:00", "2024-05-20 12:30:00"] for d in test_dates: is_valid = validate_date(d) print(f"{d} -> {'Valid' if is_valid else 'Not Valid'}") ``` #### 方法三:更改表结构以适应更大范围的需求 如果业务场景确实需要处理非常遥远未来的时间点,考虑使用更大的容器替代默认的数据类型——将现有 DATETIME 改成 BIGINT 来直接保存 Unix 时间戳形式表示的大整数即可支持任意大小数字代表无限延伸时刻。 不过需注意这会牺牲掉一部分查询便利性和标准化规范优势! --- ### 总结建议 优先从源头解决问题,即保证正确的原始数据质量;其次增强系统健壮性的措施也很关键,包括但不限于前端界面提示、后端API接口约束以及SQL脚本层面的安全防护机制等多方面努力共同防范此类异常的发生概率降至最低限度之内。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值